jiebi/CodeConvo huggingface dataset:
Code change:
}; }; <ins> wireguardPeerOptions = { options = { wireguardPeerConfig = mkOption { default = {}; example = { }; type = types.addCheck (types.attrsOf unitOption) checkWireGuardPeer; description = '' Each attribute in this set specifies an option in the <literal>[WireGuardPeer]</literal> section of the unit.  See <citerefentry><refentrytitle>systemd.network</refentrytitle> <manvolnum>5</manvolnum></citerefentry> for details. ''; }; }; }; </ins> networkOptions = commonNetworkOptions // { networkConfig = mkOption {

Related discussion:
text: This configuration: If you poke around in the configuration I linked, you should see that I disable NetworkManager and use a static configuration for my main NIC. I can't think of anything special in my config or with this machine that would affect my usage of Wireguard, but I'm also new to using Wireguard. I'm currently on nixpkgs with a few of my own commits on top of . Please run and paste the results.
It doesn't seem happy when already exists... I have done two things, both of which were necessary, to resolve this: the link manually () sure the path to the private key exists (if not, you get a different failure in the journal, with failing). (It's possible that fixing the private key path and rebooting would have been sufficient). I'm leaving this open for two reasons: user should receive a better error message in both cases. that we're in NixOS, we should assume full control of the interface and just re-configure it, instead of failing in the setup script.
I ran into this issue after trying to debug my wireguard setup. My setup is essentialy identical and I get the same error message. Running the start script that is causing the error results in this output. The offending 2 lines are .
I had to go one step further than deleting the interface. I needed to stop the via then redeploy configuration. But this solved it for me. Nixos should handle this much more gracefully.
I had to remove the routes with etc.
The command is . You can build it in your conf as pre-setup command, but it has the nasty side effect that it possible interferes with other connections.
I am still running into this issue.
Code change:
cd src-ui ''; <del> npmDepsHash = "sha256-ML1Yp3JIMbRF6kVu190ReoY7oDUtUfNkHE7dHF6YUAE="; </del> <ins> npmDepsHash = "sha256-hb2z2cPMTN5bHtUldTR5Mvgo4nZL8/S+Uhfis37gF44="; </ins> nativeBuildInputs = [ pkg-config

Related discussion:
text: Package name: paperless-ngx Latest released version: 2.12.1 <!-- Search your package here: --- Current version on the unstable channel: 2.11.6 <!-- 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. --
Code change:
buildCommand = let browserBinary = "${chromiumWV}/libexec/chromium/chromium"; getWrapperFlags = plugin: "$(< "${plugin}/nix-support/wrapper-flags")"; <del> libPath = stdenv.lib.makeLibraryPath [ libva ]; </del> <ins> libPath = stdenv.lib.makeLibraryPath [ libva pipewire_0_2 ]; </ins> in with stdenv.lib; '' mkdir -p "$out/bin"

Related discussion:
text: Project description This flag is available in most other major distros. It is necessary to enable screen sharing on wayland inside of chromium, combined with xlr-desktop-portal-wlr and pipewire. It requires the build flag and a dependency on libpipewire02. See as an example. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
that would definitely be nice to have :) I actually also noticed this but unfortunately cannot test this easily as I'm not using screen sharing. If you could contribute a PR that would be awesome (but be aware that Chromium does unfortunately take quite some time to compile). Alternatively (but less preferably) we could make the required changes with the next update and test the core functionality (as always) and you could test screen sharing after the new version is available in the binary caches. Additionally we would need to package in Nixpkgs to make this work on wlroots based compositors. On Gnome/KDE this might work out-of-the-box, but I don't know what they currently implement/provide.
was just merged w/ . I'll try building chromium w/ the flag - as you say it takes a while, so I can leave it overnight and give it a shot.
how does the situation look like with ? Is the flag available there, as in, screensharing with wayland already works there?
yes, it's available in google-chrome. ! I'm still trying to get it to work with xlr-desktop-portal-wlr - I've done this in the past, but it's not working out of the box yet with
And just to make sure, you also did set as described there?
yes I did. I'm almost got it working I think. There are a few issues out of the box: -chrome is missing the pipewire 0.2 runtime dependency, so I it as (I'm on 20.03 so pkgs.pipewire is 0.2): .pipewire service doesn't work - it doesn't seem to be setting up the path correctly. I'm trying to fix this now: My current config on 20.03 looks like: Where is the same package that was recently merged.
Code change:
buildCommand = let browserBinary = "${chromiumWV}/libexec/chromium/chromium"; getWrapperFlags = plugin: "$(< "${plugin}/nix-support/wrapper-flags")"; <del> libPath = stdenv.lib.makeLibraryPath [ libva ]; </del> <ins> libPath = stdenv.lib.makeLibraryPath [ libva pipewire_0_2 ]; </ins> in with stdenv.lib; '' mkdir -p "$out/bin"

Related discussion:
text: yeah, I'm currently already looking at it - pipewire wants to execute , but it's not in . We can patch to contain the absolute path. I'll check if it works and will get back to you.
Btw, we /really/ need a sway NixOS test, and better documentation on how to use sway. I was trying stuff until it worked, and does autologin me into a sway, but there might be a smarter way to do this, without also starting X.
The sway recommendation is to just run sway from the terminal after login - that's how I do it at least. I was able to workaround the environment issue by doing (but this is a kludge I think and shouldn't be necessary). But unfortunately it's now crashing and I'm not sure why:
Yeah, even my sddm config I also had to , otherwise pipewire complained about not being able to reach dbus: Afterwards, it segfaulted, as it wasn't able to find ; I patched to be able to find the path to , and that error message is gone. Now (apart from not being able to find bluez or rtkit) it /might/ only be some version incompatibilities, not sure: I'll see if I can get as far with your chromium PR, will merge that then, and also submit the pipewire patch.
Okay, with the pipewire patch and , It seems I'm able to share at least my own application window :tada:. I don't know yet why the alacritty window nearby isn't shown, and why "Entire Screen" is black, but that's probably due to me running sway inside X via ssdm.
pipewire PRs:
I don't think you're using pipewire in that case. xdg-desktop-portal-wlr only supports full screen sharing atm. If it is black that means it's not working. By the way I had to add pipewire02 to my system packages to prevent xdg-desktop-portal from crashing. But now there seems to be some incompatibility in the pipewire service logs when chrome tries to connect:
you should be able to cherry-pick the to not have to manually add this to $PATH.
Thanks! I'm suspecting google-chrome is compiled with a too old version of pipewire.
Code change:
buildCommand = let browserBinary = "${chromiumWV}/libexec/chromium/chromium"; getWrapperFlags = plugin: "$(< "${plugin}/nix-support/wrapper-flags")"; <del> libPath = stdenv.lib.makeLibraryPath [ libva ]; </del> <ins> libPath = stdenv.lib.makeLibraryPath [ libva pipewire_0_2 ]; </ins> in with stdenv.lib; '' mkdir -p "$out/bin"

Related discussion:
text: Enabling pipewire debug logs, it seems to be sending an incompatible format to the pipewire server (similar to ). I have got this working with chromium compiled against pipewire 0.2.7 in the past, so I'm pretty sure it should work assuming the client library is recent enough. Once the chromium package has that flag enabled I'll try to retest.
I just confirmed my last comment by building chromium locally w/ rtcusepipewire=true. It works perfectly for fullscreen sharing.
Hmm take that back - it worked the first time but not anymore :/. Not sure what lib is missing where.
Seems like xdg-desktop-portal is crashing:
This might be yet another version incompatibility problem. I propose merging (as it's built with 0.2 everywhere else too), and then see if we can get it to work if the system pipewire also is 0.2. I asked upstream about these problems in - maybe 0.3 needs to support 0.2 clients for some time until we should switch.
Heads-up: the bad client situation should have been fixed with the latest pipewire release, PR at
Thanks for your help! I'm still getting the xdg-desktop-portal crash, however. I'm guessing there is something missing from my dbus environment - or perhaps it's trying to access a file/directory not available in nixos.
could you open a new issue with some more details, like logs etc.?
Okay, I made
Code change:
]; # test_peer_interface hits a timeout <ins> # test_tcp_connection_with_forwarding fails due to dbus # creating unix socket anyway on v1.14.4 </ins> checkPhase = '' dbus-run-session --config-file=${dbus.daemon}/share/dbus-1/session.conf  ${python.interpreter} -m pytest -sv --cov=dbus_next  <del> -k "not test_peer_interface" </del> <ins> -k "not test_peer_interface and not test_tcp_connection_with_forwarding" </ins> ''; meta = with lib; {

Related discussion:
text: Try building
Just ran into the same problem when updating my system flake. For bisecting purposes, nixpkgs was my previous (working) configuration. EDIT: bisection in progress, have to do some large builds now:
Excerpt from : which seems to be the change that breaks , so we probably need to file an upstream issue.
As a workaround, something like this should work:
Note that the downgrade would undo some security fixes; see PR ... which is also why we backported this problem to 22.05.
I see...I'll wait to re-enable qtile then
Depending on how much value you place on the failing test, something like this worked for me: Modifying the package in a general overlay triggered huge rebuilds for me, so I've just replaced it inside my derivation, which is what pulls in in my system configuration.
How would you modify the package with a general overlay? Something like this didn't work for me:
This global overlay works for me, without annoying rebuilds: Note, I'm using and this is imported in . I don't know if you can use it without modifications otherwise.
I have a similar setup, I have (minus the let bindings I have in my config): So I don't see the difference between our configs...
Somehow, the overlay proposed by worked. This reaches about the limits of my Nix knowledge, but maybe is required instead of simply ? Is the only difference I can notice.
Code change:
ccrtp = callPackage ../development/libraries/ccrtp { }; cctag = callPackage ../development/libraries/cctag { <ins> stdenv = clangStdenv; </ins> tbb = tbb_2021_11; };

Related discussion:
text: Steps to reproduce the behavior: on fails (see ) Happened within CI when building () Will do. Please run and paste the result. Don't know how to run this on the failing CI machine. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
"sysctl.d/50-coredump.conf".source = "${systemd}/example/sysctl.d/50-coredump.conf"; "sysctl.d/50-default.conf".source = "${systemd}/example/sysctl.d/50-default.conf"; <ins> "tmpfiles.d/journal-nocow.conf".source = "${systemd}/example/tmpfiles.d/journal-nocow.conf"; "tmpfiles.d/static-nodes-permissions.conf".source = "${systemd}/example/tmpfiles.d/static-nodes-permissions.conf"; </ins> "tmpfiles.d/systemd.conf".source = "${systemd}/example/tmpfiles.d/systemd.conf"; <ins> "tmpfiles.d/systemd-nspawn.conf".source = "${systemd}/example/tmpfiles.d/system-nspawn.conf"; "tmpfiles.d/systemd-tmp.conf".source = "${systemd}/example/tmpfiles.d/system-tmp.conf"; "tmpfiles.d/var.conf".source = "${systemd}/example/tmpfiles.d/var.conf"; </ins> "tmpfiles.d/x11.conf".source = "${systemd}/example/tmpfiles.d/x11.conf"; "tmpfiles.d/nixos.conf".text = ''

Related discussion:
text: Describe the bug /dev/fuse isn't user read/writable To Reproduce Expected behavior Additional context I've been testing with and : Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
After further testing, I found that reverting fixes the issue. I'm guessing that this new file needs to be installed somewhere. CCing maintainers of systemd:
There are even more tmpfiles configs that we're not using. I'll check what applies to us and prepare a PR.
It would be cool if there was a test for the permissions.
I have the same issue with /dev/fuse for can't mount remote sshfs as user only as root la /dev/fuse 10.6s crw------- 1 root root 10, 229 Sep 23 14:36 /dev/fuse ~sshfs user ~/sshfs/ fuse: failed to open /dev/fuse: Permission denied Any fix we can expect soon?
Seems permissions is associated with systemd /etc/static/systemd/system/kmod-static-nodes.service
apparently that broke permissions for me, which are needed for
Strangely, on my 19.09 system does have 666 permission, despite containing a line .
I think the permission is automatically set to 666 by udev rules when the fuse module is loaded.
In my system on 19.09pre channel I have this issue manifesting in kbfsmount failing with a permission error. crw------- 1 root root 10, 229 Sep 23 21:48 /dev/fuse
Code change:
homepage    = "https://vivaldi.com"; license     = licenses.unfree; sourceProvenance = with sourceTypes; [ binaryNativeCode ]; <ins> mainProgram = "vivaldi"; </ins> maintainers = with maintainers; [ otwieracz badmutex ]; platforms   = [ "x86_64-linux" "aarch64-linux" ]; };

Related discussion:
text: Whenever is used with vivaldi to set it's binary path into a session variable for example, it produces a big warning stating that the attribute is missing and it will default to package name. a library function that needs the attribute like lib.getExe the vivaldi package as below: rebuild the config: the build process a big warning will appear stating the following: , Do the hint stated in the warning and use it like:
Code change:
imports = [ (mkAliasOptionModule [ "users" "extraUsers" ] [ "users" "users" ]) (mkAliasOptionModule [ "users" "extraGroups" ] [ "users" "groups" ]) <del> (mkChangedOptionModule [ "security" "initialRootPassword" ] [ "users" "users" "root" "initialHashedPassword" ] (cfg: if cfg.security.initialRootPassword == "!" then null else cfg.security.initialRootPassword)) </del> <ins> (mkRenamedOptionModule ["security" "initialRootPassword"] ["users" "users" "root" "initialHashedPassword"]) </ins> ]; ###### interface options = { users.mutableUsers = mkOption {

Related discussion:
text: Describe the bug There are reasons to want a system, that has no user that can log in by SSH or with their password, for example in a declarative container To Reproduce Steps to reproduce the behavior: up a minimal declarative container asserts that I will be locked out from the system and refuses to build the configuration with Expected behavior nix generates me a container that I can log in with , or maybe I don't want to log into it at all (because it's a disposable VM or something of the like). I think there should be a check whether the generated system is a container and an additional "I know what I'm doing" override for other cases. I'll create a PR once we agreed on what's best. Maintainer information: Code causing the problem: mentioning since you the check.
Is it an option to set a randomly-generated (the hash itself would be generated, not obtained by honestly hashing a password)? Recovering the password from such a hash is probably harder than a lot of other attack vectors. But an override «doLockOutEveryone» sounds fine.
Setting a password would certainly be a possibility, but somewhat (for lack of a better word) really lame. Having slept a night over it, I propose , that disables all the assertions at the bottom. I can see scenarios where two users with the same uid could be wanted. I want my unixoid to always give me enough rope to shoot myself in the leg.
What about not enabling ssh and disabling the getty? It should completely lock anyone out, unless I am missing something. Take a look at the profile.
In case of a nixos declaratively defined nixos container, you are not logged out because the root system(d) can generate a root shell without any authentication, which is why I consider this a bug. Having to "fool" the assertion to actually lock oneself out is another matter, I could live with that but I don't think it's nice behavior.
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.
Code change:
imports = [ (mkAliasOptionModule [ "users" "extraUsers" ] [ "users" "users" ]) (mkAliasOptionModule [ "users" "extraGroups" ] [ "users" "groups" ]) <del> (mkChangedOptionModule [ "security" "initialRootPassword" ] [ "users" "users" "root" "initialHashedPassword" ] (cfg: if cfg.security.initialRootPassword == "!" then null else cfg.security.initialRootPassword)) </del> <ins> (mkRenamedOptionModule ["security" "initialRootPassword"] ["users" "users" "root" "initialHashedPassword"]) </ins> ]; ###### interface options = { users.mutableUsers = mkOption {

Related discussion:
text: 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 .
This is still an issue.
I marked this as stale due to inactivity. &rarr;
Fixed via
Code change:
libreswan = handleTest ./libreswan.nix {}; librewolf = handleTest ./firefox.nix { firefoxPackage = pkgs.librewolf; }; libuiohook = handleTest ./libuiohook.nix {}; <ins> libvirtd = handleTest ./libvirtd.nix {}; </ins> lidarr = handleTest ./lidarr.nix {}; lightdm = handleTest ./lightdm.nix {}; lighttpd = handleTest ./lighttpd.nix {};

Related discussion:
text: When attempting to create a volume on a physical node pool parted is not found. Steps to reproduce the behavior: Create a physical disk node pool. Attempt to create a volume using that node pool. In this case I have created a node pool called and I am attempting to create a volume called Volume is created normally. If applicable, add screenshots to help explain your problem. I have tried to add parted manually using and overriding the package in the libvirtd module: but this did not fix the issue.
That won't work, it seems like we need to wrap to include in its . I'll take a look.
You most likely need to add it to in because libvirtd will probably call it.
Code change:
libreswan = handleTest ./libreswan.nix {}; librewolf = handleTest ./firefox.nix { firefoxPackage = pkgs.librewolf; }; libuiohook = handleTest ./libuiohook.nix {}; <ins> libvirtd = handleTest ./libvirtd.nix {}; </ins> lidarr = handleTest ./lidarr.nix {}; lightdm = handleTest ./lightdm.nix {}; lighttpd = handleTest ./lighttpd.nix {};

Related discussion:
text: I sometimes create a qemu VM in libvirt in "session mode", meaning that the libvirt daemon is running as my non-root user, and the system-wide libvirtd does not need to be running (). This VM has a network bridge, which libvirt apparently creates by calling , which in turn uses . The problem is that doesn't get fully populated until the system libvirtd gets started. Previously, in nixpkgs (from February), this wasn't noticeable because libvirtd.service was WantedBy libvirt-guests.service (which is WantedBy multi-), so libvirtd would always be started on boot to populate that directory. Now, with , this is no longer the case, and libvirtd.service does not get started (presumably, if libvirt-guests.service actually needed to start a VM, then libvirtd.service would be socket-activated, but for me this is not the case). As a result, doesn't get populated and my session-mode libvirt can't find . python: The VM's XML file defines a network bridge, which is why gets involved. the following output: The libvirt user session should be usable without first starting the system-wide libvirtd. If you start (and optionally stop) the system libvirtd.service before following the steps to reproduce, everything works fine, because the directory gets populated. Probably, should be put somewhere else, where session-mode daemons can use it without needing to have previously started system-mode libvirtd. (The same may be true of other stuff in too.) libvirt maintainers: Okay, but I'm using flakes and that channel looks old. See relevant commit hashes above.
Oof, happy to find this, it would have taken me a long time to figure out I needed to run first. Can't the sudo wrapper point to the file in the nix store?
Code change:
{ lib <del> , fetchFromGitHub </del> <ins> , fetchurl </ins> , fetchpatch , python3Packages , gnupg

Related discussion:
text: Package name: Latest released version: 3.5 <!-- Search your package here: --- Current version on the unstable channel: 3.2 Current version on the stable/release channel: 3.2 <!-- 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]:
Code change:
fingerprint = "1248 D3E1 1D11 4A85 75C9  8934 6794 D45A 488C 2EDE"; }]; }; <ins> momeemt = { name = "Mutsuha Asada"; email = "me@momee.mt"; github = "momeemt"; githubId = 43488453; keys = [{ fingerprint = "D94F EA9F 5B08 F6A1 7B8F  EB8B ACB5 4F0C BC6A A7C6"; }]; }; </ins> monaaraj = { name = "Mon Aaraj"; email = "owo69uwu69@gmail.com";

Related discussion:
text: Awesome Spectral JSON/YAML linter with OpenAPI/AsyncAPI support Spectral is a flexible object linter with out of the box support for OpenAPI v2 and v3, JSON Schema, and AsyncAPI. MIT
Should be trivial to package using .