Question:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:

let spirv_sources = { <del> # `vulkan-loader` requires a specific version of `spirv-tools` and `spirv-headers` as specified in # `<vulkan-loader-repo>/external_revisions/spirv-tools_revision`. </del> <ins> # `glslang` requires a specific version of `spirv-tools` and `spirv-headers` as specified in `known-good.json`. </ins> tools = fetchFromGitHub { owner = "KhronosGroup"; repo = "SPIRV-Tools"; <del> rev = "7e2d26c77b606b21af839b37fd21381c4a669f23"; sha256 = "1nlzj081v1xdyfz30nfs8hfcnqd072fra127h46gav179f04kss2"; </del> <ins> rev = "9e19fc0f31ceaf1f6bc907dbf17dcfded85f2ce8"; sha256 = "1zpwznq0fyvkzs5h9nnkr7g6svr0w8z6zx62xgnss17c2a5cz0lk"; </ins> }; headers = fetchFromGitHub { owner = "KhronosGroup"; repo = "SPIRV-Headers"; <del> rev = "2bb92e6fe2c6aa410152fc6c63443f452acb1a65"; sha256 = "1rgjd7kpa7xpbwpzd6m3f6yq44s9xn5ddhz135213pxwbi5c0c26"; </del> <ins> rev = "ce309203d7eceaf908bea8862c27f3e0749f7d00"; sha256 = "1sv1iy2d46sg7r3xy591db6fn9h78wd079yvfa87vwmwsdkhiqhm"; </ins> }; };


Question:
Tried to make a system upgrade, got this: Obviously, upgrade can't be completed. have in . run Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
This looks like the offending line: This could be related to what file system you are using?
Actually this looks like unrelated to glslang. Works on master:

stdenv.mkDerivation rec { name = "spirv-tools-${version}"; <del> version = "2017-09-01"; </del> <ins> version = "2018-02-05"; </ins> src = spirv_sources.tools; patchPhase = ''ln -sv ${spirv_sources.headers} external/spirv-headers'';


Question:
does not build after "boto{3,core}: {1.6.0,1.9.3} -{1.7.9,1.10.9}" by system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Whoops, sorry about that! I keep forgetting they're all linked

in py.pkgs.buildPythonApplication rec { pname = "awscli"; <del> version = "1.14.50"; </del> <ins> version = "1.15.10"; </ins> src = py.pkgs.fetchPypi { inherit pname version; <del> sha256 = "1yiwj7cl9r1k9226mdq6pcmrs044k7p3d133lzgv9rb1dgp4053c"; </del> <ins> sha256 = "0nwpanbfx5h0bad8wwvvbhpjf9r6n885bbv2w8mw7vijdgclkq8x"; </ins> }; # No tests included


Question:
does not build after "boto{3,core}: {1.6.0,1.9.3} -{1.7.9,1.10.9}" by system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Whoops, sorry about that! I keep forgetting they're all linked

less ]; <ins> postPatch = '' for i in {py,cfg}; do substituteInPlace setup.$i --replace "botocore==1.10.10" "botocore>=1.10.9,<=1.11" done ''; </ins> postInstall = '' mkdir -p $out/etc/bash_completion.d echo "complete -C $out/bin/aws_completer aws" > $out/etc/bash_completion.d/awscli


Question:
Open a gnome-terminal and go to any directory other than $HOME. Right-click in the terminal and click "New Terminal" A new terminal opens, but the current directory is $HOME. This has probably always been like this in NixOS. On traditionally systems is sourced which exposes the shell $PWD to the terminal. In NixOS that file lies "dormant" in the store: Users can workaround this by manually sourcing the file: (probably best to pick the one in gnome-terminal's clousure) system: host os: multi-user?: sandbox: version: channels(ole): channels(root): nixpkgs: Gnome installed by
Is that supposed to be done for new windows? It works for me with new tabs, I think.
It does after sourcing the file so I assume it's intended. I'll check on an other system when I get the chance. I get the same behavior with new tabs (does not preserve $PWD when is not sourced) Can you check the content of (bash) or (zsh)?
I use fish-shell and the pwd just seems to be preserved.
Seems fish notifies various terminals . More context:
Would something like the following work? This global solution is not very nice but I am not sure how to address it correctly.
The alternative might be to add something like the linked fish config to : The script checks if the shell isn't bash or zsh, so it should be safe to do so. Did a quick test in a VM and it seems to do the trick.
For some reason the above snippet doesn't "initialize" for me. I have to manually run . Weird. I even some manual trace and see that is sourced. But still it doesn't work. I'm using bash, but perhaps I have some untracked stuff in .bashrc that is interfering? I'm currently unable to debug using the NixOS VM. stops in stage-1 at "mke2fs 1.44.1 (24-Mar-2018)". EDIT: typo
hmm, weird, I'm specifically running this diff on unstable: I'm able to launch bash (from zsh) and the directory successfully updates when creating new terminals, though I can't quite remember if I tested things out with bash in a VM. edit: managed to do ctrl-return
Thanks to I am now able to use "nixos-rebuild build-vm" again (on NixOS 18.03). I can confirm the above patch () fixes it. (I guess why it doesn't work on my physical laptop is due to some imperative changes in my $HOME.) Would you like to make a PR?
This seems to strangely only work in bash, has anyone gotten this to work with ZSH? I suppose I could source the file manually though I'm not sure which path the ${} refers to?
I have this patch in my tree which works for ZSH: Edit: I see I posted this exact diff above :laughing: Kinda forgot about this, should really subit a PR.
I've that bit into my config and have done a rebuild, but don't get the desired behavior. Where does the actually output to (which file) - would this not be needed in my .zshrc?
It should show up in . The exact patch I posted relies on btw. You could also include it straight in your configuration if you're not using gnome.
Many thanks - I'm a bit cautious to try that line as I've previously had various issues with fonts / themes / icons. I've found a direct copy of from my old Arch installation and just sourcing that manually for now -works perfectly! In the event it's useful to someone:
Sorry, guess I wasn't clear. I meant including in your , that way it isn't hidden behind the flag.
I'm struggling to find a way to represent that configuration snippet as a nixos option that can be generalized to just mean or support for vte terminals. For example it could be but vte isn't a program.
Since the VTE lib comes from , what about something like ? In the same way we have . also have a bunch of shell configuration (, , , ...), so it could make sens.
Yay, great suggestion I can do that :+1:
My old solution posted no longer seems to work after upgrading to nixos 20.09. I can't seem to find the actual solution to this, any pointers?
What was your old solution? If you enable gnome-terminal you will have the vte module enabled. If not enable them manually
I've got: However I still seem to run into the same issue, after running . As for the old solution - that was sourcing the file I had from arch linux. I also tried: And sourcing that file with - that still does not seem to work.
I managed to fix this by setting to instead of . No idea if this setting perhaps got reset somehow - but it worked previously. :)

<ins> # VTE { config, pkgs, lib, ... }: with lib; let vteInitSnippet = '' # Show current working directory in VTE terminals window title. # Supports both bash and zsh, requires interactive shell. . ${pkgs.vte}/etc/profile.d/vte.sh ''; in { options = { programs.bash.vteIntegration = mkOption { default = false; type = types.bool; description = '' Whether to enable Bash integration for VTE terminals. This allows it to preserve the current directory of the shell across terminals. ''; }; programs.zsh.vteIntegration = mkOption { default = false; type = types.bool; description = '' Whether to enable Zsh integration for VTE terminals. This allows it to preserve the current directory of the shell across terminals. ''; }; }; config = mkMerge [ (mkIf config.programs.bash.vteIntegration { programs.bash.interactiveShellInit = vteInitSnippet; }) (mkIf config.programs.zsh.vteIntegration { programs.zsh.interactiveShellInit = vteInitSnippet; }) ]; } </ins>


Question:
Open a gnome-terminal and go to any directory other than $HOME. Right-click in the terminal and click "New Terminal" A new terminal opens, but the current directory is $HOME. This has probably always been like this in NixOS. On traditionally systems is sourced which exposes the shell $PWD to the terminal. In NixOS that file lies "dormant" in the store: Users can workaround this by manually sourcing the file: (probably best to pick the one in gnome-terminal's clousure) system: host os: multi-user?: sandbox: version: channels(ole): channels(root): nixpkgs: Gnome installed by
Is that supposed to be done for new windows? It works for me with new tabs, I think.
It does after sourcing the file so I assume it's intended. I'll check on an other system when I get the chance. I get the same behavior with new tabs (does not preserve $PWD when is not sourced) Can you check the content of (bash) or (zsh)?
I use fish-shell and the pwd just seems to be preserved.
Seems fish notifies various terminals . More context:
Would something like the following work? This global solution is not very nice but I am not sure how to address it correctly.
The alternative might be to add something like the linked fish config to : The script checks if the shell isn't bash or zsh, so it should be safe to do so. Did a quick test in a VM and it seems to do the trick.
For some reason the above snippet doesn't "initialize" for me. I have to manually run . Weird. I even some manual trace and see that is sourced. But still it doesn't work. I'm using bash, but perhaps I have some untracked stuff in .bashrc that is interfering? I'm currently unable to debug using the NixOS VM. stops in stage-1 at "mke2fs 1.44.1 (24-Mar-2018)". EDIT: typo
hmm, weird, I'm specifically running this diff on unstable: I'm able to launch bash (from zsh) and the directory successfully updates when creating new terminals, though I can't quite remember if I tested things out with bash in a VM. edit: managed to do ctrl-return
Thanks to I am now able to use "nixos-rebuild build-vm" again (on NixOS 18.03). I can confirm the above patch () fixes it. (I guess why it doesn't work on my physical laptop is due to some imperative changes in my $HOME.) Would you like to make a PR?
This seems to strangely only work in bash, has anyone gotten this to work with ZSH? I suppose I could source the file manually though I'm not sure which path the ${} refers to?
I have this patch in my tree which works for ZSH: Edit: I see I posted this exact diff above :laughing: Kinda forgot about this, should really subit a PR.
I've that bit into my config and have done a rebuild, but don't get the desired behavior. Where does the actually output to (which file) - would this not be needed in my .zshrc?
It should show up in . The exact patch I posted relies on btw. You could also include it straight in your configuration if you're not using gnome.
Many thanks - I'm a bit cautious to try that line as I've previously had various issues with fonts / themes / icons. I've found a direct copy of from my old Arch installation and just sourcing that manually for now -works perfectly! In the event it's useful to someone:
Sorry, guess I wasn't clear. I meant including in your , that way it isn't hidden behind the flag.
I'm struggling to find a way to represent that configuration snippet as a nixos option that can be generalized to just mean or support for vte terminals. For example it could be but vte isn't a program.
Since the VTE lib comes from , what about something like ? In the same way we have . also have a bunch of shell configuration (, , , ...), so it could make sens.
Yay, great suggestion I can do that :+1:
My old solution posted no longer seems to work after upgrading to nixos 20.09. I can't seem to find the actual solution to this, any pointers?
What was your old solution? If you enable gnome-terminal you will have the vte module enabled. If not enable them manually
I've got: However I still seem to run into the same issue, after running . As for the old solution - that was sourcing the file I had from arch linux. I also tried: And sourcing that file with - that still does not seem to work.
I managed to fix this by setting to instead of . No idea if this setting perhaps got reset somehow - but it worked previously. :)

./config/unix-odbc-drivers.nix ./config/users-groups.nix ./config/vpnc.nix <ins> ./config/vte.nix </ins> ./config/zram.nix ./hardware/acpilight.nix ./hardware/all-firmware.nix


Question:
Open a gnome-terminal and go to any directory other than $HOME. Right-click in the terminal and click "New Terminal" A new terminal opens, but the current directory is $HOME. This has probably always been like this in NixOS. On traditionally systems is sourced which exposes the shell $PWD to the terminal. In NixOS that file lies "dormant" in the store: Users can workaround this by manually sourcing the file: (probably best to pick the one in gnome-terminal's clousure) system: host os: multi-user?: sandbox: version: channels(ole): channels(root): nixpkgs: Gnome installed by
Is that supposed to be done for new windows? It works for me with new tabs, I think.
It does after sourcing the file so I assume it's intended. I'll check on an other system when I get the chance. I get the same behavior with new tabs (does not preserve $PWD when is not sourced) Can you check the content of (bash) or (zsh)?
I use fish-shell and the pwd just seems to be preserved.
Seems fish notifies various terminals . More context:
Would something like the following work? This global solution is not very nice but I am not sure how to address it correctly.
The alternative might be to add something like the linked fish config to : The script checks if the shell isn't bash or zsh, so it should be safe to do so. Did a quick test in a VM and it seems to do the trick.
For some reason the above snippet doesn't "initialize" for me. I have to manually run . Weird. I even some manual trace and see that is sourced. But still it doesn't work. I'm using bash, but perhaps I have some untracked stuff in .bashrc that is interfering? I'm currently unable to debug using the NixOS VM. stops in stage-1 at "mke2fs 1.44.1 (24-Mar-2018)". EDIT: typo
hmm, weird, I'm specifically running this diff on unstable: I'm able to launch bash (from zsh) and the directory successfully updates when creating new terminals, though I can't quite remember if I tested things out with bash in a VM. edit: managed to do ctrl-return
Thanks to I am now able to use "nixos-rebuild build-vm" again (on NixOS 18.03). I can confirm the above patch () fixes it. (I guess why it doesn't work on my physical laptop is due to some imperative changes in my $HOME.) Would you like to make a PR?
This seems to strangely only work in bash, has anyone gotten this to work with ZSH? I suppose I could source the file manually though I'm not sure which path the ${} refers to?
I have this patch in my tree which works for ZSH: Edit: I see I posted this exact diff above :laughing: Kinda forgot about this, should really subit a PR.
I've that bit into my config and have done a rebuild, but don't get the desired behavior. Where does the actually output to (which file) - would this not be needed in my .zshrc?
It should show up in . The exact patch I posted relies on btw. You could also include it straight in your configuration if you're not using gnome.
Many thanks - I'm a bit cautious to try that line as I've previously had various issues with fonts / themes / icons. I've found a direct copy of from my old Arch installation and just sourcing that manually for now -works perfectly! In the event it's useful to someone:
Sorry, guess I wasn't clear. I meant including in your , that way it isn't hidden behind the flag.
I'm struggling to find a way to represent that configuration snippet as a nixos option that can be generalized to just mean or support for vte terminals. For example it could be but vte isn't a program.
Since the VTE lib comes from , what about something like ? In the same way we have . also have a bunch of shell configuration (, , , ...), so it could make sens.
Yay, great suggestion I can do that :+1:
My old solution posted no longer seems to work after upgrading to nixos 20.09. I can't seem to find the actual solution to this, any pointers?
What was your old solution? If you enable gnome-terminal you will have the vte module enabled. If not enable them manually
I've got: However I still seem to run into the same issue, after running . As for the old solution - that was sourcing the file I had from arch linux. I also tried: And sourcing that file with - that still does not seem to work.
I managed to fix this by setting to instead of . No idea if this setting perhaps got reset somehow - but it worked previously. :)

./programs/fuse.nix ./programs/gnome-disks.nix ./programs/gnome-documents.nix <ins> ./programs/gnome-terminal.nix </ins> ./programs/gpaste.nix ./programs/gnupg.nix ./programs/gphoto2.nix


Question:
Open a gnome-terminal and go to any directory other than $HOME. Right-click in the terminal and click "New Terminal" A new terminal opens, but the current directory is $HOME. This has probably always been like this in NixOS. On traditionally systems is sourced which exposes the shell $PWD to the terminal. In NixOS that file lies "dormant" in the store: Users can workaround this by manually sourcing the file: (probably best to pick the one in gnome-terminal's clousure) system: host os: multi-user?: sandbox: version: channels(ole): channels(root): nixpkgs: Gnome installed by
Is that supposed to be done for new windows? It works for me with new tabs, I think.
It does after sourcing the file so I assume it's intended. I'll check on an other system when I get the chance. I get the same behavior with new tabs (does not preserve $PWD when is not sourced) Can you check the content of (bash) or (zsh)?
I use fish-shell and the pwd just seems to be preserved.
Seems fish notifies various terminals . More context:
Would something like the following work? This global solution is not very nice but I am not sure how to address it correctly.
The alternative might be to add something like the linked fish config to : The script checks if the shell isn't bash or zsh, so it should be safe to do so. Did a quick test in a VM and it seems to do the trick.
For some reason the above snippet doesn't "initialize" for me. I have to manually run . Weird. I even some manual trace and see that is sourced. But still it doesn't work. I'm using bash, but perhaps I have some untracked stuff in .bashrc that is interfering? I'm currently unable to debug using the NixOS VM. stops in stage-1 at "mke2fs 1.44.1 (24-Mar-2018)". EDIT: typo
hmm, weird, I'm specifically running this diff on unstable: I'm able to launch bash (from zsh) and the directory successfully updates when creating new terminals, though I can't quite remember if I tested things out with bash in a VM. edit: managed to do ctrl-return
Thanks to I am now able to use "nixos-rebuild build-vm" again (on NixOS 18.03). I can confirm the above patch () fixes it. (I guess why it doesn't work on my physical laptop is due to some imperative changes in my $HOME.) Would you like to make a PR?
This seems to strangely only work in bash, has anyone gotten this to work with ZSH? I suppose I could source the file manually though I'm not sure which path the ${} refers to?
I have this patch in my tree which works for ZSH: Edit: I see I posted this exact diff above :laughing: Kinda forgot about this, should really subit a PR.
I've that bit into my config and have done a rebuild, but don't get the desired behavior. Where does the actually output to (which file) - would this not be needed in my .zshrc?
It should show up in . The exact patch I posted relies on btw. You could also include it straight in your configuration if you're not using gnome.
Many thanks - I'm a bit cautious to try that line as I've previously had various issues with fonts / themes / icons. I've found a direct copy of from my old Arch installation and just sourcing that manually for now -works perfectly! In the event it's useful to someone:
Sorry, guess I wasn't clear. I meant including in your , that way it isn't hidden behind the flag.
I'm struggling to find a way to represent that configuration snippet as a nixos option that can be generalized to just mean or support for vte terminals. For example it could be but vte isn't a program.
Since the VTE lib comes from , what about something like ? In the same way we have . also have a bunch of shell configuration (, , , ...), so it could make sens.
Yay, great suggestion I can do that :+1:
My old solution posted no longer seems to work after upgrading to nixos 20.09. I can't seem to find the actual solution to this, any pointers?
What was your old solution? If you enable gnome-terminal you will have the vte module enabled. If not enable them manually
I've got: However I still seem to run into the same issue, after running . As for the old solution - that was sourcing the file I had from arch linux. I also tried: And sourcing that file with - that still does not seem to work.
I managed to fix this by setting to instead of . No idea if this setting perhaps got reset somehow - but it worked previously. :)

./services/desktops/gnome3/gnome-remote-desktop.nix ./services/desktops/gnome3/gnome-online-miners.nix ./services/desktops/gnome3/gnome-settings-daemon.nix <del> ./services/desktops/gnome3/gnome-terminal-server.nix </del> ./services/desktops/gnome3/gnome-user-share.nix ./services/desktops/gnome3/gvfs.nix ./services/desktops/gnome3/rygel.nix


Question:
Open a gnome-terminal and go to any directory other than $HOME. Right-click in the terminal and click "New Terminal" A new terminal opens, but the current directory is $HOME. This has probably always been like this in NixOS. On traditionally systems is sourced which exposes the shell $PWD to the terminal. In NixOS that file lies "dormant" in the store: Users can workaround this by manually sourcing the file: (probably best to pick the one in gnome-terminal's clousure) system: host os: multi-user?: sandbox: version: channels(ole): channels(root): nixpkgs: Gnome installed by
Is that supposed to be done for new windows? It works for me with new tabs, I think.
It does after sourcing the file so I assume it's intended. I'll check on an other system when I get the chance. I get the same behavior with new tabs (does not preserve $PWD when is not sourced) Can you check the content of (bash) or (zsh)?
I use fish-shell and the pwd just seems to be preserved.
Seems fish notifies various terminals . More context:
Would something like the following work? This global solution is not very nice but I am not sure how to address it correctly.
The alternative might be to add something like the linked fish config to : The script checks if the shell isn't bash or zsh, so it should be safe to do so. Did a quick test in a VM and it seems to do the trick.
For some reason the above snippet doesn't "initialize" for me. I have to manually run . Weird. I even some manual trace and see that is sourced. But still it doesn't work. I'm using bash, but perhaps I have some untracked stuff in .bashrc that is interfering? I'm currently unable to debug using the NixOS VM. stops in stage-1 at "mke2fs 1.44.1 (24-Mar-2018)". EDIT: typo
hmm, weird, I'm specifically running this diff on unstable: I'm able to launch bash (from zsh) and the directory successfully updates when creating new terminals, though I can't quite remember if I tested things out with bash in a VM. edit: managed to do ctrl-return
Thanks to I am now able to use "nixos-rebuild build-vm" again (on NixOS 18.03). I can confirm the above patch () fixes it. (I guess why it doesn't work on my physical laptop is due to some imperative changes in my $HOME.) Would you like to make a PR?
This seems to strangely only work in bash, has anyone gotten this to work with ZSH? I suppose I could source the file manually though I'm not sure which path the ${} refers to?
I have this patch in my tree which works for ZSH: Edit: I see I posted this exact diff above :laughing: Kinda forgot about this, should really subit a PR.
I've that bit into my config and have done a rebuild, but don't get the desired behavior. Where does the actually output to (which file) - would this not be needed in my .zshrc?
It should show up in . The exact patch I posted relies on btw. You could also include it straight in your configuration if you're not using gnome.
Many thanks - I'm a bit cautious to try that line as I've previously had various issues with fonts / themes / icons. I've found a direct copy of from my old Arch installation and just sourcing that manually for now -works perfectly! In the event it's useful to someone:
Sorry, guess I wasn't clear. I meant including in your , that way it isn't hidden behind the flag.
I'm struggling to find a way to represent that configuration snippet as a nixos option that can be generalized to just mean or support for vte terminals. For example it could be but vte isn't a program.
Since the VTE lib comes from , what about something like ? In the same way we have . also have a bunch of shell configuration (, , , ...), so it could make sens.
Yay, great suggestion I can do that :+1:
My old solution posted no longer seems to work after upgrading to nixos 20.09. I can't seem to find the actual solution to this, any pointers?
What was your old solution? If you enable gnome-terminal you will have the vte module enabled. If not enable them manually
I've got: However I still seem to run into the same issue, after running . As for the old solution - that was sourcing the file I had from arch linux. I also tried: And sourcing that file with - that still does not seem to work.
I managed to fix this by setting to instead of . No idea if this setting perhaps got reset somehow - but it worked previously. :)

<ins> # GNOME Terminal. { config, pkgs, lib, ... }: with lib; let cfg = config.programs.gnome-terminal; in { # Added 2019-08-19 imports = [ (mkRenamedOptionModule [ "services" "gnome3" "gnome-terminal-server" "enable" ] [ "programs" "gnome-terminal" "enable" ]) ]; options = { programs.gnome-terminal.enable = mkEnableOption "GNOME Terminal"; }; config = mkIf cfg.enable { environment.systemPackages = [ pkgs.gnome3.gnome-terminal ]; services.dbus.packages = [ pkgs.gnome3.gnome-terminal ]; systemd.packages = [ pkgs.gnome3.gnome-terminal ]; programs.bash.vteIntegration = true; programs.zsh.vteIntegration = true; }; } </ins>


Question:
Open a gnome-terminal and go to any directory other than $HOME. Right-click in the terminal and click "New Terminal" A new terminal opens, but the current directory is $HOME. This has probably always been like this in NixOS. On traditionally systems is sourced which exposes the shell $PWD to the terminal. In NixOS that file lies "dormant" in the store: Users can workaround this by manually sourcing the file: (probably best to pick the one in gnome-terminal's clousure) system: host os: multi-user?: sandbox: version: channels(ole): channels(root): nixpkgs: Gnome installed by
Is that supposed to be done for new windows? It works for me with new tabs, I think.
It does after sourcing the file so I assume it's intended. I'll check on an other system when I get the chance. I get the same behavior with new tabs (does not preserve $PWD when is not sourced) Can you check the content of (bash) or (zsh)?
I use fish-shell and the pwd just seems to be preserved.
Seems fish notifies various terminals . More context:
Would something like the following work? This global solution is not very nice but I am not sure how to address it correctly.
The alternative might be to add something like the linked fish config to : The script checks if the shell isn't bash or zsh, so it should be safe to do so. Did a quick test in a VM and it seems to do the trick.
For some reason the above snippet doesn't "initialize" for me. I have to manually run . Weird. I even some manual trace and see that is sourced. But still it doesn't work. I'm using bash, but perhaps I have some untracked stuff in .bashrc that is interfering? I'm currently unable to debug using the NixOS VM. stops in stage-1 at "mke2fs 1.44.1 (24-Mar-2018)". EDIT: typo
hmm, weird, I'm specifically running this diff on unstable: I'm able to launch bash (from zsh) and the directory successfully updates when creating new terminals, though I can't quite remember if I tested things out with bash in a VM. edit: managed to do ctrl-return
Thanks to I am now able to use "nixos-rebuild build-vm" again (on NixOS 18.03). I can confirm the above patch () fixes it. (I guess why it doesn't work on my physical laptop is due to some imperative changes in my $HOME.) Would you like to make a PR?
This seems to strangely only work in bash, has anyone gotten this to work with ZSH? I suppose I could source the file manually though I'm not sure which path the ${} refers to?
I have this patch in my tree which works for ZSH: Edit: I see I posted this exact diff above :laughing: Kinda forgot about this, should really subit a PR.
I've that bit into my config and have done a rebuild, but don't get the desired behavior. Where does the actually output to (which file) - would this not be needed in my .zshrc?
It should show up in . The exact patch I posted relies on btw. You could also include it straight in your configuration if you're not using gnome.
Many thanks - I'm a bit cautious to try that line as I've previously had various issues with fonts / themes / icons. I've found a direct copy of from my old Arch installation and just sourcing that manually for now -works perfectly! In the event it's useful to someone:
Sorry, guess I wasn't clear. I meant including in your , that way it isn't hidden behind the flag.
I'm struggling to find a way to represent that configuration snippet as a nixos option that can be generalized to just mean or support for vte terminals. For example it could be but vte isn't a program.
Since the VTE lib comes from , what about something like ? In the same way we have . also have a bunch of shell configuration (, , , ...), so it could make sens.
Yay, great suggestion I can do that :+1:
My old solution posted no longer seems to work after upgrading to nixos 20.09. I can't seem to find the actual solution to this, any pointers?
What was your old solution? If you enable gnome-terminal you will have the vte module enabled. If not enable them manually
I've got: However I still seem to run into the same issue, after running . As for the old solution - that was sourcing the file I had from arch linux. I also tried: And sourcing that file with - that still does not seem to work.
I managed to fix this by setting to instead of . No idea if this setting perhaps got reset somehow - but it worked previously. :)

<del> # GNOME Documents daemon. { config, pkgs, lib, ... }: with lib; { ###### interface options = { services.gnome3.gnome-terminal-server = { enable = mkOption { type = types.bool; default = false; description = '' Whether to enable GNOME Terminal server service, needed for gnome-terminal. ''; }; }; }; ###### implementation config = mkIf config.services.gnome3.gnome-terminal-server.enable { environment.systemPackages = [ pkgs.gnome3.gnome-terminal ]; services.dbus.packages = [ pkgs.gnome3.gnome-terminal ]; systemd.packages = [ pkgs.gnome3.gnome-terminal ]; }; } </del>


Question:
Open a gnome-terminal and go to any directory other than $HOME. Right-click in the terminal and click "New Terminal" A new terminal opens, but the current directory is $HOME. This has probably always been like this in NixOS. On traditionally systems is sourced which exposes the shell $PWD to the terminal. In NixOS that file lies "dormant" in the store: Users can workaround this by manually sourcing the file: (probably best to pick the one in gnome-terminal's clousure) system: host os: multi-user?: sandbox: version: channels(ole): channels(root): nixpkgs: Gnome installed by
Is that supposed to be done for new windows? It works for me with new tabs, I think.
It does after sourcing the file so I assume it's intended. I'll check on an other system when I get the chance. I get the same behavior with new tabs (does not preserve $PWD when is not sourced) Can you check the content of (bash) or (zsh)?
I use fish-shell and the pwd just seems to be preserved.
Seems fish notifies various terminals . More context:
Would something like the following work? This global solution is not very nice but I am not sure how to address it correctly.
The alternative might be to add something like the linked fish config to : The script checks if the shell isn't bash or zsh, so it should be safe to do so. Did a quick test in a VM and it seems to do the trick.
For some reason the above snippet doesn't "initialize" for me. I have to manually run . Weird. I even some manual trace and see that is sourced. But still it doesn't work. I'm using bash, but perhaps I have some untracked stuff in .bashrc that is interfering? I'm currently unable to debug using the NixOS VM. stops in stage-1 at "mke2fs 1.44.1 (24-Mar-2018)". EDIT: typo
hmm, weird, I'm specifically running this diff on unstable: I'm able to launch bash (from zsh) and the directory successfully updates when creating new terminals, though I can't quite remember if I tested things out with bash in a VM. edit: managed to do ctrl-return
Thanks to I am now able to use "nixos-rebuild build-vm" again (on NixOS 18.03). I can confirm the above patch () fixes it. (I guess why it doesn't work on my physical laptop is due to some imperative changes in my $HOME.) Would you like to make a PR?
This seems to strangely only work in bash, has anyone gotten this to work with ZSH? I suppose I could source the file manually though I'm not sure which path the ${} refers to?
I have this patch in my tree which works for ZSH: Edit: I see I posted this exact diff above :laughing: Kinda forgot about this, should really subit a PR.
I've that bit into my config and have done a rebuild, but don't get the desired behavior. Where does the actually output to (which file) - would this not be needed in my .zshrc?
It should show up in . The exact patch I posted relies on btw. You could also include it straight in your configuration if you're not using gnome.
Many thanks - I'm a bit cautious to try that line as I've previously had various issues with fonts / themes / icons. I've found a direct copy of from my old Arch installation and just sourcing that manually for now -works perfectly! In the event it's useful to someone:
Sorry, guess I wasn't clear. I meant including in your , that way it isn't hidden behind the flag.
I'm struggling to find a way to represent that configuration snippet as a nixos option that can be generalized to just mean or support for vte terminals. For example it could be but vte isn't a program.
Since the VTE lib comes from , what about something like ? In the same way we have . also have a bunch of shell configuration (, , , ...), so it could make sens.
Yay, great suggestion I can do that :+1:
My old solution posted no longer seems to work after upgrading to nixos 20.09. I can't seem to find the actual solution to this, any pointers?
What was your old solution? If you enable gnome-terminal you will have the vte module enabled. If not enable them manually
I've got: However I still seem to run into the same issue, after running . As for the old solution - that was sourcing the file I had from arch linux. I also tried: And sourcing that file with - that still does not seem to work.
I managed to fix this by setting to instead of . No idea if this setting perhaps got reset somehow - but it worked previously. :)

services.gnome3.gnome-online-accounts.enable = mkDefault true; services.gnome3.gnome-remote-desktop.enable = mkDefault true; services.gnome3.gnome-settings-daemon.enable = true; <del> services.gnome3.gnome-terminal-server.enable = mkDefault true; </del> services.gnome3.gnome-user-share.enable = mkDefault true; services.gnome3.gvfs.enable = true; services.gnome3.rygel.enable = mkDefault true;


Question:
Open a gnome-terminal and go to any directory other than $HOME. Right-click in the terminal and click "New Terminal" A new terminal opens, but the current directory is $HOME. This has probably always been like this in NixOS. On traditionally systems is sourced which exposes the shell $PWD to the terminal. In NixOS that file lies "dormant" in the store: Users can workaround this by manually sourcing the file: (probably best to pick the one in gnome-terminal's clousure) system: host os: multi-user?: sandbox: version: channels(ole): channels(root): nixpkgs: Gnome installed by
Is that supposed to be done for new windows? It works for me with new tabs, I think.
It does after sourcing the file so I assume it's intended. I'll check on an other system when I get the chance. I get the same behavior with new tabs (does not preserve $PWD when is not sourced) Can you check the content of (bash) or (zsh)?
I use fish-shell and the pwd just seems to be preserved.
Seems fish notifies various terminals . More context:
Would something like the following work? This global solution is not very nice but I am not sure how to address it correctly.
The alternative might be to add something like the linked fish config to : The script checks if the shell isn't bash or zsh, so it should be safe to do so. Did a quick test in a VM and it seems to do the trick.
For some reason the above snippet doesn't "initialize" for me. I have to manually run . Weird. I even some manual trace and see that is sourced. But still it doesn't work. I'm using bash, but perhaps I have some untracked stuff in .bashrc that is interfering? I'm currently unable to debug using the NixOS VM. stops in stage-1 at "mke2fs 1.44.1 (24-Mar-2018)". EDIT: typo
hmm, weird, I'm specifically running this diff on unstable: I'm able to launch bash (from zsh) and the directory successfully updates when creating new terminals, though I can't quite remember if I tested things out with bash in a VM. edit: managed to do ctrl-return
Thanks to I am now able to use "nixos-rebuild build-vm" again (on NixOS 18.03). I can confirm the above patch () fixes it. (I guess why it doesn't work on my physical laptop is due to some imperative changes in my $HOME.) Would you like to make a PR?
This seems to strangely only work in bash, has anyone gotten this to work with ZSH? I suppose I could source the file manually though I'm not sure which path the ${} refers to?
I have this patch in my tree which works for ZSH: Edit: I see I posted this exact diff above :laughing: Kinda forgot about this, should really subit a PR.
I've that bit into my config and have done a rebuild, but don't get the desired behavior. Where does the actually output to (which file) - would this not be needed in my .zshrc?
It should show up in . The exact patch I posted relies on btw. You could also include it straight in your configuration if you're not using gnome.
Many thanks - I'm a bit cautious to try that line as I've previously had various issues with fonts / themes / icons. I've found a direct copy of from my old Arch installation and just sourcing that manually for now -works perfectly! In the event it's useful to someone:
Sorry, guess I wasn't clear. I meant including in your , that way it isn't hidden behind the flag.
I'm struggling to find a way to represent that configuration snippet as a nixos option that can be generalized to just mean or support for vte terminals. For example it could be but vte isn't a program.
Since the VTE lib comes from , what about something like ? In the same way we have . also have a bunch of shell configuration (, , , ...), so it could make sens.
Yay, great suggestion I can do that :+1:
My old solution posted no longer seems to work after upgrading to nixos 20.09. I can't seem to find the actual solution to this, any pointers?
What was your old solution? If you enable gnome-terminal you will have the vte module enabled. If not enable them manually
I've got: However I still seem to run into the same issue, after running . As for the old solution - that was sourcing the file I had from arch linux. I also tried: And sourcing that file with - that still does not seem to work.
I managed to fix this by setting to instead of . No idea if this setting perhaps got reset somehow - but it worked previously. :)

programs.file-roller.enable = mkDefault true; programs.gnome-disks.enable = mkDefault true; programs.gnome-documents.enable = mkDefault true; <ins> programs.gnome-terminal.enable = mkDefault true; </ins> # If gnome3 is installed, build vim for gtk3 too. nixpkgs.config.vim.gui = "gtk3";


Question:
nixpkgs rev
I wonder if this is another case of the socket path being too long...
Tests appear to work iff sandboxing is disabled.
Same issue reproduced locally on
If the hydra build failed, how did this get released to the 18.03 stable channel?
It is not a release blocking build. Here are the constituents: I'm more curious how it ever worked. I can't really imagine that it hasn't changed since the sandbox was enabled on Hydra.
I tried some older revisions and it really looks like DBD-Pg tests never worked in a sandbox. The package was last updated 2015. Bumping to current DBD-Pg 3.7.4 doesn't help either - it first results in an error about the socket path being too long, and after patching that the tests freeze at the same point as with 3.5.3. So let's stick to 3.5.3 and just set .
Sounds good to me, will you or shall I?
I'm working on it.

makeMakerFlags = "POSTGRES_HOME=${postgresql}"; <ins> # tests freeze in a sandbox doCheck = false; </ins> meta = { homepage = http://search.cpan.org/dist/DBD-Pg/; description = "DBI PostgreSQL interface";


Question:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.

<del> { stdenv, fetchFromRepoOrCz, fetchurl, nasm, perl, python3, libuuid, mtools, makeWrapper }: </del> <ins> { stdenv, fetchgit, fetchurl, fetchpatch, nasm, perl, python3, libuuid, mtools, makeWrapper }: </ins> stdenv.mkDerivation { <del> name = "syslinux-2019-02-07"; </del> <ins> pname = "syslinux"; version = "unstable-20190207"; </ins> # This is syslinux-6.04-pre3^1; syslinux-6.04-pre3 fails to run. # Same issue here https://www.syslinux.org/archives/2019-February/026330.html <del> src = fetchFromRepoOrCz { repo = "syslinux"; </del> <ins> src = fetchgit { url = "https://repo.or.cz/syslinux"; </ins> rev = "b40487005223a78c3bb4c300ef6c436b3f6ec1f7"; <del> sha256 = "1qrxl1114sr2i2791z9rf8v53g200aq30f08808d7i8qnmgvxl2w"; </del> <ins> sha256 = "1acf6byx7i6vz8hq6mra526g8mf7fmfhid211y8nq0v6px7d3aqs"; fetchSubmodules = true; </ins> }; patches = let


Question:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.

url = mkURL "fa1349f1" "0002-gfxboot-menu-label.patch"; sha256 = "06ifgzbpjj4picpj17zgprsfi501zf4pp85qjjgn29i5rs291zni"; }) <del> (fetchurl { url = mkURL "477e56d2" "0005-gnu-efi-version-compatibility.patch"; sha256 = "041568b4abb79wynyps1n04lg4fr26rc3sbjncz99pp0mbz0ajlm"; </del> <ins> (fetchpatch { url = "https://git.archlinux.org/svntogit/packages.git/plain/trunk/0005-gnu-efi-version-compatibility.patch?h=packages/syslinux"; sha256 = "0fbqz56hj8az8ws26m39hyp3l5fvcbzvzdddqz3x6n56hzdpz1p6"; </ins> }) (fetchurl { # mbr.bin: too big (452 > 440)


Question:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.

# fix tests substituteInPlace tests/unittest/include/unittest/unittest.h  --replace /usr/include/ "" <ins> # Hack to get `gcc -m32' to work without having 32-bit Glibc headers. mkdir gnu-efi/inc/ia32/gnu touch gnu-efi/inc/ia32/gnu/stubs-32.h </ins> ''; nativeBuildInputs = [ nasm perl python3 ];


Question:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.

makeFlags = [ "BINDIR=$(out)/bin" "SBINDIR=$(out)/sbin" <del> "LIBDIR=$(out)/lib" "INCDIR=$(out)/include" </del> "DATADIR=$(out)/share" "MANDIR=$(out)/share/man" "PERL=perl" <del> "bios" </del> ]; doCheck = false; # fails. some fail in a sandbox, others require qemu


Question:
When using with and the build fails when trying to write to a in the It works fine if the list of packages is empty or only contains packages that are normally in the environment. Oddly enough, if you run in the it does not produce an error, but it also does not actually include the package, No idea if this is related to system: "x86_64-darwin" host os: Darwin Kernel Version 16.7.0, Sierra multi-user?: no version: nix-env (Nix) 1.11.4 nixpkgs: nixpkgs-channels, commit
I believe the root cause of this problem is that the libraries like , etc are being installed in but the extra packages by are being installed in and the is only looking in one of those locations. I have a work-around hack which I will post when I get a chance.
Can you confirm that fixes this for you?

ghcCommand'    = if isGhcjs then "ghcjs" else "ghc"; ghcCommand = "${ghc.targetPrefix}${ghcCommand'}"; ghcCommandCaps= lib.toUpper ghcCommand'; <del> libDir        = if isHaLVM then "$out/lib/HaLVM-${ghc.version}" else "$out/lib/${ghcCommand}-${ghc.version}"; </del> <ins> libDir        = if isHaLVM then "$out/lib/HaLVM-${ghc.version}" else if isGhcjs then "$out/libexec" else "$out/lib/${ghcCommand}-${ghc.version}"; </ins> docDir        = "$out/share/doc/ghc/html"; packageCfgDir = "${libDir}/package.conf.d"; paths         = lib.filter (x: x ? isHaskellLibrary) (lib.closePropagation packages);


Question:
This should be . A similar issue happens for 7.59.
Ha! Yes! Currently this happens: Will submit a PR for this shortly, thanks!

configureFlags = [ ( if sslSupport then "--with-ssl=${openssl.crossDrv}" else "--without-ssl" ) ( if gnutlsSupport then "--with-gnutls=${gnutls.crossDrv}" else "--without-gnutls" ) <del> "--with-random /dev/urandom" </del> <ins> "--with-random=/dev/urandom" </ins> ]; };


Question:
After got merged, and is in the nixos-unstable channel, I noticed after I rebuilt my system that when sddm starts and I type in my password it just goes black and restarts sddm. Meaning that I can never reach the desktop :( I could also not find anything useful in the journal. cc
In a VT, try this as root:
Ahh that makes perfect sense and worked :hand: Is there any real way to make sure this doesn't happen for someone else?
There was a PR some time ago that was supposed to address this (it was merged) that would simply clear out the directory on start but it looks like that didn't do the trick. I don't remember which. IMHO, the proper way to handle this is something like this:
I also often have this problem.. could you open a pull request that removes the old solution and that adds your solution?
The commit was - I'll PR this.

Xsetup = pkgs.writeScript "Xsetup" '' #!/bin/sh <del> # Prior to Qt 5.9.2, there is a QML cache invalidation bug which sometimes # strikes new Plasma 5 releases. If the QML cache is not invalidated, SDDM # will segfault without explanation. We really tore our hair out for awhile # before finding the bug: # https://bugreports.qt.io/browse/QTBUG-62302 # We work around the problem by deleting the QML cache before startup. It # will be regenerated, causing a small but perceptible delay when SDDM # starts. rm -fr /var/lib/sddm/.cache/sddm-greeter/qmlcache </del> ${cfg.setupScript} '';


Question:
After got merged, and is in the nixos-unstable channel, I noticed after I rebuilt my system that when sddm starts and I type in my password it just goes black and restarts sddm. Meaning that I can never reach the desktop :( I could also not find anything useful in the journal. cc
In a VT, try this as root:
Ahh that makes perfect sense and worked :hand: Is there any real way to make sure this doesn't happen for someone else?
There was a PR some time ago that was supposed to address this (it was merged) that would simply clear out the directory on start but it looks like that didn't do the trick. I don't remember which. IMHO, the proper way to handle this is something like this:
I also often have this problem.. could you open a pull request that removes the old solution and that adds your solution?
The commit was - I'll PR this.

# To enable user switching, allow sddm to allocate TTYs/displays dynamically. services.xserver.tty = null; services.xserver.display = null; <ins> systemd.tmpfiles.rules = [ # Prior to Qt 5.9.2, there is a QML cache invalidation bug which sometimes # strikes new Plasma 5 releases. If the QML cache is not invalidated, SDDM # will segfault without explanation. We really tore our hair out for awhile # before finding the bug: # https://bugreports.qt.io/browse/QTBUG-62302 # We work around the problem by deleting the QML cache before startup. # This was supposedly fixed in Qt 5.9.2 however it has been reported with # 5.10 and 5.11 as well. The initial workaround was to delete the directory # in the Xsetup script but that doesn't do anything. # Instead we use tmpfiles.d to ensure it gets wiped. # This causes a small but perceptible delay when SDDM starts. "e ${config.users.users.sddm.home}/.cache - - - 0" ]; </ins> }; }


Question:
Passing to a Haskell package has no effect, the resulting binary is . CC
I have checked that at the time runs, shows as but shows as .
The solution seems to be to pass  in when is given.
PR with the fix at

"--enable-library-for-ghci" # TODO: Should this be configurable? ] ++ optionals (enableDeadCodeElimination && (stdenv.lib.versionOlder "8.0.1" ghc.version)) [ "--ghc-option=-split-sections" <ins> ] ++ optionals dontStrip [ "--disable-library-stripping" "--disable-executable-stripping" </ins> ] ++ optionals isGhcjs [ "--ghcjs" ] ++ optionals isCross ([


Question:
I expect all of these to not return "No such file or directory" and I expect the "bad interpreter" to be patched. I think it still "works", but compilation output should be clean such that when debugging something in the future there is not first a mess of other warnings to go through. Multiple issues: system: host os: multi-user?: sandbox: version: nixpkgs:
cc maintainers
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 . on the on .
The build currently complains that is missing: This program comes from ; I believe needs in .
I marked this as stale due to inactivity. →
As above, I think this is just a matter of adding the right .
I marked this as stale due to inactivity. →

./hplip-3.20.11-nixos-cups-ppd-search-path.patch ]; <del> prePatch = '' </del> <ins> postPatch = '' # https://github.com/NixOS/nixpkgs/issues/44230 substituteInPlace createPPD.sh  --replace ppdc "${cups}/bin/ppdc"  --replace "gzip -c" "gzip -cn" </ins> # HPLIP hardcodes absolute paths everywhere. Nuke from orbit. find . -type f -exec sed -i  -e s,/etc/hp,$out/etc/hp,g


Question:
I expect all of these to not return "No such file or directory" and I expect the "bad interpreter" to be patched. I think it still "works", but compilation output should be clean such that when debugging something in the future there is not first a mess of other warnings to go through. Multiple issues: system: host os: multi-user?: sandbox: version: nixpkgs:
cc maintainers
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 . on the on .
The build currently complains that is missing: This program comes from ; I believe needs in .
I marked this as stale due to inactivity. →
As above, I think this is just a matter of adding the right .
I marked this as stale due to inactivity. →

export CUPS_DATADIR="${cups}/share/cups" ''; <ins> postConfigure = '' # don't save timestamp, in order to improve reproducibility substituteInPlace Makefile  --replace "GZIP_ENV = --best" "GZIP_ENV = --best -n" ''; </ins> enableParallelBuilding = true; #


Question:
seem the Keras preprocessing routines were split off into their own package in 2.0. The Nix version was then updated to 2.0 in commit without verifying that it worked. This broke the package as it is now necessary to also package the new package and provide it as a dependency to
We do semi-automatic batch upgrades to the Python packages because not all of them are well maintained. This also means we cannot fix all breakage that occurs during these batch upgrades, however we try to fix as much as possible. If you have the time, please package the new dependency and make a pull request.
Thanks for taking care of that.

<ins> { lib, buildPythonPackage, fetchPypi, numpy, h5py }: buildPythonPackage rec { pname = "Keras_Applications"; version = "1.0.4"; src = fetchPypi { inherit pname version; sha256 = "8c95300328630ae74fb0828b6fa38269a25c0228a02f1e5181753bfd48961f49"; }; # Cyclic dependency: keras-applications requires keras, which requires keras-applications postPatch = '' sed -i "s/keras>=[^']*//" setup.py ''; # No tests in PyPI tarball doCheck = false; propagatedBuildInputs = [ numpy h5py ]; meta = with lib; { description = "Reference implementations of popular deep learning models"; homepage = https://github.com/keras-team/keras-applications; license = licenses.mit; }; } </ins>


Question:
seem the Keras preprocessing routines were split off into their own package in 2.0. The Nix version was then updated to 2.0 in commit without verifying that it worked. This broke the package as it is now necessary to also package the new package and provide it as a dependency to
We do semi-automatic batch upgrades to the Python packages because not all of them are well maintained. This also means we cannot fix all breakage that occurs during these batch upgrades, however we try to fix as much as possible. If you have the time, please package the new dependency and make a pull request.
Thanks for taking care of that.

<ins> { lib, buildPythonPackage, fetchPypi, numpy, scipy, six }: buildPythonPackage rec { pname = "Keras_Preprocessing"; version = "1.0.2"; src = fetchPypi { inherit pname version; sha256 = "f5306554d2b454d825b36f35e327744f5477bd2ae21017f1a93b2097bed6757e"; }; # Cyclic dependency: keras-preprocessing requires keras, which requires keras-preprocessing postPatch = '' sed -i "s/keras>=[^']*//" setup.py ''; # No tests in PyPI tarball doCheck = false; propagatedBuildInputs = [ numpy scipy six ]; meta = with lib; { description = "Easy data preprocessing and data augmentation for deep learning models"; homepage = https://github.com/keras-team/keras-preprocessing; license = licenses.mit; }; } </ins>


Question:
seem the Keras preprocessing routines were split off into their own package in 2.0. The Nix version was then updated to 2.0 in commit without verifying that it worked. This broke the package as it is now necessary to also package the new package and provide it as a dependency to
We do semi-automatic batch upgrades to the Python packages because not all of them are well maintained. This also means we cannot fix all breakage that occurs during these batch upgrades, however we try to fix as much as possible. If you have the time, please package the new dependency and make a pull request.
Thanks for taking care of that.

{ stdenv, buildPythonPackage, fetchPypi , pytest, pytestcov, pytestpep8, pytest_xdist , six, numpy, scipy, pyyaml, h5py <ins> , keras-applications, keras-preprocessing </ins> }: buildPythonPackage rec { pname = "Keras"; <del> version = "2.2.0"; </del> <ins> version = "2.2.2"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "5b8499d157af217f1a5ee33589e774127ebc3e266c833c22cb5afbb0ed1734bf"; </del> <ins> sha256 = "468d98da104ec5c3dbb10c2ef6bb345ab154f6ca2d722d4c250ef4d6105de17a"; </ins> }; checkInputs = [


Question:
seem the Keras preprocessing routines were split off into their own package in 2.0. The Nix version was then updated to 2.0 in commit without verifying that it worked. This broke the package as it is now necessary to also package the new package and provide it as a dependency to
We do semi-automatic batch upgrades to the Python packages because not all of them are well maintained. This also means we cannot fix all breakage that occurs during these batch upgrades, however we try to fix as much as possible. If you have the time, please package the new dependency and make a pull request.
Thanks for taking care of that.

propagatedBuildInputs = [ six pyyaml numpy scipy h5py <ins> keras-applications keras-preprocessing </ins> ]; # Couldn't get tests working


Question:
seem the Keras preprocessing routines were split off into their own package in 2.0. The Nix version was then updated to 2.0 in commit without verifying that it worked. This broke the package as it is now necessary to also package the new package and provide it as a dependency to
We do semi-automatic batch upgrades to the Python packages because not all of them are well maintained. This also means we cannot fix all breakage that occurs during these batch upgrades, however we try to fix as much as possible. If you have the time, please package the new dependency and make a pull request.
Thanks for taking care of that.

Keras = callPackage ../development/python-modules/keras { }; <ins> keras-applications = callPackage ../development/python-modules/keras-applications { }; keras-preprocessing = callPackage ../development/python-modules/keras-preprocessing { }; </ins> Lasagne = buildPythonPackage rec { name = "Lasagne-${version}"; version = "0.1";


Question:
Commit introduced type specification for (which was absent before), but this specification is wrong. From within release-18.03, import the tomcat module from the master branch, and create a minimal Tomcat configuration that uses : And see it fails: When using the native module from release-18.03, everything works. system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:
It's only semi-related, but why on earth is the type of a list of packages, and not just a list of paths or strings?? It severely limits the configuration options for no apparent gain.
For the record, was an issue about overly restrictive type of .

type = types.listOf (types.submodule { options = { name = mkOption { <del> type = types.listOf types.str; </del> <ins> type = types.str; </ins> description = "name of the virtualhost"; <ins> }; webapps = mkOption { type = types.listOf types.path; description = '' List containing web application WAR files and/or directories containing web applications and configuration files for the virtual host. ''; </ins> default = []; }; };


Question:
Not sure if I'm doing something wrong, but while returns all ghc822 packages, throws an error: Do I need to somehow feed ghc-compact into this? My info:
gets the listing of packages going again, but the package depending on still don't build, as they have a constrain and ghc 8.0.2 has base 4.9.*

filepath = null; ghc-boot = null; ghc-boot-th = null; <ins> ghc-compact = null; </ins> ghc-prim = null; ghci = null; haskeline = null;


Question:
Shotcut in theory supports LADSPA plugins. However, LADSPA plugins are not found by Shotcut on NixOS version Install a bunch of LADSPA plugins (by listing them in ) Open Shotcut Add effects to a track Look for audio effects: no LADSPA plugins are shown Please run and paste the results.
cc maintainers
I tried to build shotcut and mlt with ladspa-sdk and set LADSPA_PATH, but did not manage to get the ladspa plugins working yet. ,-(
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 . on the on .
found out why: configure is using , which is not available, and therefore does disable ladspa. Preparing a PR.

, mkDerivation , SDL2 , frei0r <ins> , ladspaPlugins </ins> , gettext , mlt , jack1


Question:
Shotcut in theory supports LADSPA plugins. However, LADSPA plugins are not found by Shotcut on NixOS version Install a bunch of LADSPA plugins (by listing them in ) Open Shotcut Add effects to a track Look for audio effects: no LADSPA plugins are shown Please run and paste the results.
cc maintainers
I tried to build shotcut and mlt with ladspa-sdk and set LADSPA_PATH, but did not manage to get the ladspa plugins working yet. ,-(
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 . on the on .
found out why: configure is using , which is not available, and therefore does disable ladspa. Preparing a PR.

, qtwebsockets , qtquickcontrols2 , qtgraphicaleffects <del> , libmlt </del> , qmake , qttools , genericUpdater , common-updater-scripts }: <del> assert stdenv.lib.versionAtLeast libmlt.version "6.22.1"; </del> assert stdenv.lib.versionAtLeast mlt.version "6.22.1"; mkDerivation rec {


Question:
Shotcut in theory supports LADSPA plugins. However, LADSPA plugins are not found by Shotcut on NixOS version Install a bunch of LADSPA plugins (by listing them in ) Open Shotcut Add effects to a track Look for audio effects: no LADSPA plugins are shown Please run and paste the results.
cc maintainers
I tried to build shotcut and mlt with ladspa-sdk and set LADSPA_PATH, but did not manage to get the ladspa plugins working yet. ,-(
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 . on the on .
found out why: configure is using , which is not available, and therefore does disable ladspa. Preparing a PR.

buildInputs = [ SDL2 frei0r <ins> ladspaPlugins </ins> gettext mlt <del> libmlt </del> qtbase qtmultimedia qtx11extras


Question:
Shotcut in theory supports LADSPA plugins. However, LADSPA plugins are not found by Shotcut on NixOS version Install a bunch of LADSPA plugins (by listing them in ) Open Shotcut Add effects to a track Look for audio effects: no LADSPA plugins are shown Please run and paste the results.
cc maintainers
I tried to build shotcut and mlt with ladspa-sdk and set LADSPA_PATH, but did not manage to get the ladspa plugins working yet. ,-(
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 . on the on .
found out why: configure is using , which is not available, and therefore does disable ladspa. Preparing a PR.

qtgraphicaleffects ]; <del> NIX_CFLAGS_COMPILE = "-I${libmlt}/include/mlt++ -I${libmlt}/include/mlt"; </del> <ins> NIX_CFLAGS_COMPILE = "-I${mlt.dev}/include/mlt++ -I${mlt.dev}/include/mlt"; </ins> qmakeFlags = [ "QMAKE_LRELEASE=${stdenv.lib.getDev qttools}/bin/lrelease" "SHOTCUT_VERSION=${version}"


Question:
Shotcut in theory supports LADSPA plugins. However, LADSPA plugins are not found by Shotcut on NixOS version Install a bunch of LADSPA plugins (by listing them in ) Open Shotcut Add effects to a track Look for audio effects: no LADSPA plugins are shown Please run and paste the results.
cc maintainers
I tried to build shotcut and mlt with ladspa-sdk and set LADSPA_PATH, but did not manage to get the ladspa plugins working yet. ,-(
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 . on the on .
found out why: configure is using , which is not available, and therefore does disable ladspa. Preparing a PR.

qtWrapperArgs = [ "--prefix FREI0R_PATH : ${frei0r}/lib/frei0r-1" <ins> "--prefix LADSPA_PATH : ${ladspaPlugins}/lib/ladspa" </ins> "--prefix LD_LIBRARY_PATH : ${stdenv.lib.makeLibraryPath [ jack1 SDL2 ]}" "--prefix PATH : ${mlt}/bin" ];


Question:
Shotcut in theory supports LADSPA plugins. However, LADSPA plugins are not found by Shotcut on NixOS version Install a bunch of LADSPA plugins (by listing them in ) Open Shotcut Add effects to a track Look for audio effects: no LADSPA plugins are shown Please run and paste the results.
cc maintainers
I tried to build shotcut and mlt with ladspa-sdk and set LADSPA_PATH, but did not manage to get the ladspa plugins working yet. ,-(
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 . on the on .
found out why: configure is using , which is not available, and therefore does disable ladspa. Preparing a PR.

<del> { stdenv, fetchFromGitHub, SDL, ffmpeg, frei0r, libjack2, libdv, libsamplerate , libvorbis, libxml2, makeWrapper, movit, pkgconfig, sox, qtbase, qtsvg , fftw, vid-stab, opencv3, ladspa-sdk, genericUpdater, common-updater-scripts </del> <ins> { stdenv , fetchFromGitHub , SDL , ffmpeg , frei0r , libjack2 , libdv , libsamplerate , libvorbis , libxml2 , movit , pkgconfig , sox , qtbase , qtsvg , fftw , vid-stab , opencv3 , ladspa-sdk , genericUpdater , common-updater-scripts , ladspaPlugins , mkDerivation , which </ins> }: let inherit (stdenv.lib) getDev; in <del> stdenv.mkDerivation rec { </del> <ins> mkDerivation rec { </ins> pname = "mlt"; version = "6.22.1";


Question:
Shotcut in theory supports LADSPA plugins. However, LADSPA plugins are not found by Shotcut on NixOS version Install a bunch of LADSPA plugins (by listing them in ) Open Shotcut Add effects to a track Look for audio effects: no LADSPA plugins are shown Please run and paste the results.
cc maintainers
I tried to build shotcut and mlt with ladspa-sdk and set LADSPA_PATH, but did not manage to get the ladspa plugins working yet. ,-(
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 . on the on .
found out why: configure is using , which is not available, and therefore does disable ladspa. Preparing a PR.

}; buildInputs = [ <del> SDL ffmpeg frei0r libjack2 libdv libsamplerate libvorbis libxml2 makeWrapper movit pkgconfig qtbase qtsvg sox fftw vid-stab opencv3 </del> <ins> SDL ffmpeg frei0r libjack2 libdv libsamplerate libvorbis libxml2 movit pkgconfig qtbase qtsvg sox fftw vid-stab opencv3 </ins> ladspa-sdk <ins> ladspaPlugins </ins> ]; <ins> nativeBuildInputs = [ which ]; </ins> outputs = [ "out" "dev" ]; # Mostly taken from: # http://www.kdenlive.org/user-manual/downloading-and-installing-kdenlive/installing-source/installing-mlt-rendering-engine configureFlags = [ <del> "--avformat-swscale" "--enable-gpl" "--enable-gpl" "--enable-gpl3" </del> <ins> "--avformat-swscale" "--enable-gpl" "--enable-gpl3" </ins> "--enable-opengl" ];


Question:
Shotcut in theory supports LADSPA plugins. However, LADSPA plugins are not found by Shotcut on NixOS version Install a bunch of LADSPA plugins (by listing them in ) Open Shotcut Add effects to a track Look for audio effects: no LADSPA plugins are shown Please run and paste the results.
cc maintainers
I tried to build shotcut and mlt with ladspa-sdk and set LADSPA_PATH, but did not manage to get the ladspa plugins working yet. ,-(
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 . on the on .
found out why: configure is using , which is not available, and therefore does disable ladspa. Preparing a PR.

enableParallelBuilding = true; <del> postInstall = '' wrapProgram $out/bin/melt --prefix FREI0R_PATH : ${frei0r}/lib/frei0r-1 </del> <ins> qtWrapperArgs = [ "--prefix FREI0R_PATH : ${frei0r}/lib/frei0r-1" "--prefix LADSPA_PATH : ${ladspaPlugins}/lib/ladspa" ]; postInstall = '' </ins> # Remove an unnecessary reference to movit.dev. s=${movit.dev}/include t=$(for ((i = 0; i < ''${#s}; i++)); do echo -n X; done)


Question:
Shotcut in theory supports LADSPA plugins. However, LADSPA plugins are not found by Shotcut on NixOS version Install a bunch of LADSPA plugins (by listing them in ) Open Shotcut Add effects to a track Look for audio effects: no LADSPA plugins are shown Please run and paste the results.
cc maintainers
I tried to build shotcut and mlt with ladspa-sdk and set LADSPA_PATH, but did not manage to get the ladspa plugins working yet. ,-(
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 . on the on .
found out why: configure is using , which is not available, and therefore does disable ladspa. Preparing a PR.

scudcloud = callPackage ../applications/networking/instant-messengers/scudcloud { }; <del> shotcut = libsForQt514.callPackage ../applications/video/shotcut { libmlt = mlt; }; </del> <ins> shotcut = libsForQt5.callPackage ../applications/video/shotcut { }; </ins> shogun = callPackage ../applications/science/machine-learning/shogun { stdenv = gcc8Stdenv;


Question:
when trying to build vim with configuration from it fails with: 'gdk/gdkx.h' file not found This issue just started to happen 5 days ago when I updated my nix to 2.1.2, before that it did build this derivation. On Darwin: Try to run in nix repl: system: host os: multi-user?: sandbox: version: channels(oren): nixpkgs:
So this only seems to affect the configurable vim, not the regular one? That would suggest that there's a simple compatibility fix that someone made to the main derivation that wasn't applied to configurable. I can't look at it right now but anyone in know what's up with this header?
Did you override guiSupport or set ?
my call to configurablenixpath as gui = "auto", if this what you mean.
Yeah that's the problem, gtk is included conditionally depending on what version is requested.
Running without it(leaving the default value for the GUI) is still causing the error.
I'm still having this issue - did you get it working in the end? Would you mind sharing how..?
I had my vim pkgs set pinned to 1803 and it worked. today I was trying to update the latest nixpkgs to build vim with and I still get this error.
In Darwin(MacOS 10.15) I was not able to compile a vim from vim/configurable but for what I was looking for (compile it with python and Lua support) I was able to compile from this is what worked for me:
Worked around this by disabling the GUI, works well if you don't need it:

, features          ? "huge" # One of tiny, small, normal, big or huge , wrapPythonDrv     ? false <del> , guiSupport        ? config.vim.gui or "gtk3" </del> <ins> , guiSupport        ? config.vim.gui or (if stdenv.isDarwin then "gtk2" else "gtk3") </ins> , luaSupport        ? config.vim.lua or true , perlSupport       ? config.vim.perl or false      # Perl interpreter , pythonSupport     ? config.vim.python or true     # Python interpreter


Question:
If account-daemon restarts in a gnome3 session it totally breaks and becomes unusable. What happens for me if account-daemon restarts is that I see the screen flash like the login animation from gdm. All programs are still up. But the mouse is frozen and I can't even switch to a tty with my keyboard. The only thing that it actually responds to seems to be Ctrl+Alt+Delete which triggers a reboot. And this indicates that I'm actually in a tty but I see an image of my gnome-session. This is a problem when doing nixos-rebuild switch etc. I had a proposed fix in but dropped my branch because I was unsure if that fixed the issue, but I'm having that overriden in my personal config here: And it's much better while doing or or so than it was before. This can be tested by just doing a . system: host os: multi-user?: sandbox: version: channels(etu): channels(root): nixpkgs: cc
This is also breaking my ui whenever I try activate a configuration. Stack trace of , with and compiled with . Stack trace of from a coredump, with regular libraries:
Filed bug upstream:
For those looking to work around this, it should be sufficient to remove any config. (Untested).
This still an issue
oh, sorry. I've forgotten about this issue and stopped running gnome like 8 months ago. So I have no idea :D
I'm able to confirm that when using in GDM that restarting the accounts-daemon does crash the session. And isn't a sufficient workaround.
I'm seeing a very similar stack trace from in my user session after a -triggered . I'm not using GDM auto-login. I don't have debug symbols but here's the stack trace from . Note that the top of the stack is still in in libaccountsservice. When I went looking at the source for these functions, the only thing which made sense was that returned , which led me to the upstream bug and then to here.
Had the exact same issue today. my backtrace is identical to that of
This needs an upstream fix as reported in This is very confirmed.
I've been testing the workaround on one laptop and not on another. On the laptop without the workaround, upgrading from to caused to crash. On the laptop with the workaround, upgrading to that version from an older version () did not lead to a crash. why did you say this is not a sufficient workaround? It's kind of a pain to test so I can easily believe I'm missing something. Is it important to restart on upgrade? I assume no other distro has reported this bug or there'd hopefully be more activity in the upstream bug report. Are other distros just not restarting it on upgrade for some reason, maybe? Perhaps it's that… because NixOS treats as changed if any of its transitive dependencies change, we upgrade+restart it a lot more frequently than anybody else does? Maybe nobody else is noticing because changes rarely and other distros aren't triggering the crash often enough to annoy people into investigating?
I'm also seeing this crash and UI hang during . I am not using at all (I'm using ). I'm able to recover the hung session if I can get to a terminal by running . I left a note in with log output.
Still happens on NixOS 20.03 because the fix was never ported. Here is my backtrace from gdm, which seems to be exactly the same as reported earlier in this thread.

''; patches = [ <ins> # https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/55 (fetchpatch { url = "https://gitlab.freedesktop.org/accountsservice/accountsservice/-/merge_requests/58.patch"; sha256 = "1pnwq4ycnryb2kkgvnz44qzm71240ybqj6507wynlkdsw8180fdw"; }) </ins> (substituteAll { src = ./fix-paths.patch; inherit shadow coreutils;


Question:
Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc

sed -i 's/os_trace((.*)");$/printf(1n");/g' ./projects/compiler-rt/lib/sanitizer_common/sanitizer_mac.cc substituteInPlace CMakeLists.txt  <del> --replace 'set(CMAKE_INSTALL_NAME_DIR "@rpath")' "set(CMAKE_INSTALL_NAME_DIR "$out/lib")"  </del> <ins> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir)"  </ins> --replace 'set(CMAKE_INSTALL_RPATH "@executable_path/../lib")' "" '' + ''


Question:
Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc

--replace 'set(COMPILER_RT_HAS_TSAN TRUE)' 'set(COMPILER_RT_HAS_TSAN FALSE)' substituteInPlace CMakeLists.txt  <del> --replace 'set(CMAKE_INSTALL_NAME_DIR "@rpath")' "set(CMAKE_INSTALL_NAME_DIR "$lib/lib")"  </del> <ins> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir)"  </ins> --replace 'set(CMAKE_INSTALL_RPATH "@executable_path/../lib")' "" '' # Patch llvm-config to return correct library path based on --link-{shared,static}.


Question:
Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc

--replace 'set(COMPILER_RT_HAS_TSAN TRUE)' 'set(COMPILER_RT_HAS_TSAN FALSE)' substituteInPlace cmake/modules/AddLLVM.cmake  <del> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir INSTALL_NAME_DIR "$lib/lib")"  </del> <ins> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir)"  </ins> --replace 'set(_install_rpath "@loader_path/../lib" ''${extra_libdir})' "" '' # Patch llvm-config to return correct library path based on --link-{shared,static}.


Question:
Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc

postPatch = stdenv.lib.optionalString stdenv.isDarwin '' substituteInPlace cmake/modules/AddLLVM.cmake  <del> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir INSTALL_NAME_DIR "$lib/lib")"  </del> <ins> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir)"  </ins> --replace 'set(_install_rpath "@loader_path/../lib" ''${extra_libdir})' "" '' # Patch llvm-config to return correct library path based on --link-{shared,static}.


Question:
Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc

nativeBuildInputs = [ cmake python which swig ]; buildInputs = [ ncurses zlib libedit libxml2 llvm ] <del> ++ stdenv.lib.optionals stdenv.isDarwin [ darwin.libobjc darwin.apple_sdk.libs.xpc darwin.apple_sdk.frameworks.Foundation darwin.bootstrap_cmds darwin.apple_sdk.frameworks.Carbon darwin.apple_sdk.frameworks.Cocoa ]; </del> <ins> ++ stdenv.lib.optionals stdenv.isDarwin [ darwin.libobjc darwin.apple_sdk.libs.xpc darwin.apple_sdk.frameworks.Foundation darwin.bootstrap_cmds darwin.apple_sdk.frameworks.Carbon darwin.apple_sdk.frameworks.Cocoa darwin.cf-private ]; </ins> CXXFLAGS = "-fno-rtti"; hardeningDisable = [ "format" ];


Question:
Run , observe: Please run and paste the results.
Very weird... It must have come in from a recent update. You can find libLLDB in the lldb derivation:
/cc

postPatch = optionalString stdenv.isDarwin '' substituteInPlace cmake/modules/AddLLVM.cmake  <del> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir INSTALL_NAME_DIR "$lib/lib")"  </del> <ins> --replace 'set(_install_name_dir INSTALL_NAME_DIR "@rpath")' "set(_install_name_dir)"  </ins> --replace 'set(_install_rpath "@loader_path/../lib" ''${extra_libdir})' "" '' # Patch llvm-config to return correct library path based on --link-{shared,static}.


Question:
On running I get: Add to and run. system: host os: multi-user?: sandbox: version: channels(lev): channels(root): nixpkgs:
Well, the output has at least changed a bit:
my pull request fixes the . It broke down because the package had moved to but requires . But according to the browser is discontinued and `firefox-esr-5.2' is marked as unsecure so I would rather advocate for removing this package altogether.

<del> { stdenv, fetchgit, unzip, firefox-esr, makeWrapper }: </del> <ins> { stdenv, fetchgit, unzip, firefox-esr-52, makeWrapper }: </ins> stdenv.mkDerivation rec { pkgname = "conkeror"; version = "1.0.4"; name = "${pkgname}-${version}"; src = fetchgit { url = git://repo.or.cz/conkeror.git; rev = "refs/tags/${version}";


Question:
On running I get: Add to and run. system: host os: multi-user?: sandbox: version: channels(lev): channels(root): nixpkgs:
Well, the output has at least changed a bit:
my pull request fixes the . It broke down because the package had moved to but requires . But according to the browser is discontinued and `firefox-esr-5.2' is marked as unsecure so I would rather advocate for removing this package altogether.

mkdir -p $out/libexec/conkeror cp -r * $out/libexec/conkeror <del> makeWrapper ${firefox-esr}/bin/firefox $out/bin/conkeror  </del> <ins> makeWrapper ${firefox-esr-52}/bin/firefox $out/bin/conkeror  </ins> --add-flags "-app $out/libexec/conkeror/application.ini" '';


Question:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .

patchShebangs meson_post_install.py ''; <del> postInstall = '' rm $out/share/applications/mimeinfo.cache ''; </del> meta = { homepage = https://fontmanager.github.io/; description = "Simple font management for GTK+ desktop environments";


Question:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .

"-Dsystemdunitdir=lib/systemd/system" ]; <del> postInstall = '' rm $out/share/applications/mimeinfo.cache ''; </del> passthru = { updateScript = gnome3.updateScript { packageName = pname;


Question:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .

nativeBuildInputs = [ pkgconfig ]; buildInputs = [ glib libintl ]; <ins> setupHook = ./setup-hook.sh; </ins> meta = { homepage = http://www.freedesktop.org/wiki/Software/desktop-file-utils; description = "Command line utilities for working with .desktop files";


Question:
Whenever I try to install both and I get a collision error because both derivations contain : Do files need to be in the packages? The same problem can be reproduced by building a environment where both and are in:
I have the same problem between and .

<ins> # Remove mimeinfo cache mimeinfoPreFixupPhase() { rm -f $out/share/applications/mimeinfo.cache } preFixupPhases="$preFixupPhases mimeinfoPreFixupPhase" </ins>


Question:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

services.openssh.enable = false; services.lshd.enable = true; programs.ssh.startAgent = false; <del> services.xserver.startGnuPGAgent = true; </del> # TODO: GNU dico. # TODO: GNU Inetutils' inetd.


Question:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

(mkRemovedOptionModule [ "services" "openvpn" "enable" ]) (mkRemovedOptionModule [ "services" "printing" "cupsFilesConf" ]) (mkRemovedOptionModule [ "services" "printing" "cupsdConf" ]) <ins> (mkRemovedOptionModule [ "services" "xserver" "startGnuPGAgent" ]) </ins> ]; }


Question:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

fi ''} <del> ${optionalString cfg.startGnuPGAgent '' if test -z "$SSH_AUTH_SOCK"; then # Restart this script as a child of the GnuPG agent. exec "${pkgs.gnupg}/bin/gpg-agent"                          --enable-ssh-support --daemon                              --pinentry-program "${pkgs.pinentry}/bin/pinentry-gtk-2"   --write-env-file "$HOME/.gpg-agent-info"                   "$0" "$sessionType" fi ''} </del> # Handle being called by kdm. if test "''${1:0:1}" = /; then eval exec "$1"; fi


Question:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.

''; }; <del> startGnuPGAgent = mkOption { type = types.bool; default = false; description = '' Whether to start the GnuPG agent when you log in.  The GnuPG agent remembers private keys for you so that you don't have to type in passphrases every time you make an SSH connection or sign/encrypt data.  Use <command>ssh-add</command> to add a key to the agent. ''; }; </del> startDbusSession = mkOption { type = types.bool; default = true;