Question:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

cd obj-* ''; <del> makeFlags = lib.optionals ltoSupport [ "AR=${buildStdenv.cc.bintools.bintools}/bin/llvm-ar" "LLVM_OBJDUMP=${buildStdenv.cc.bintools.bintools}/bin/llvm-objdump" "NM=${buildStdenv.cc.bintools.bintools}/bin/llvm-nm" "RANLIB=${buildStdenv.cc.bintools.bintools}/bin/llvm-ranlib" "STRIP=${buildStdenv.cc.bintools.bintools}/bin/llvm-strip" ] ++ extraMakeFlags; </del> <ins> makeFlags = extraMakeFlags; </ins> enableParallelBuilding = true; doCheck = false; # "--disable-tests" above


Question:
YouTube tabs reliably crash within a few minutes on nixpkgs-built firefox Steps to reproduce the behavior: firefox from latest (NixOS/nixpkgs to some youtube user's video list up and down for a bit This doesn't happen with my previous env (using firefox 92.0.1, I think NixOS/nixpkgs but I haven't confirmed), nor with . It does happen with . Also, the page is not available on the nixpkgs-built firefox. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I think it happens when you hover over a video and it starts showing the preview.
Yep that does it!
Possibly this bug?
Seems familiar. Will try the fix they suggest.
Note that in bisecting I've found a commit with the same version of ff but not this bug.
I don't think it's the same bug, I'm able to watch both linked videos (as long as I don't mouse-over a preview on the side)
It's happening for me as well, not sure why though
Not happening with firefox-bin 94.0
As said in the issue it doesn't happen with firefox-bin at all (also checked that myself) (also not 94.0.1)
Also happening for me (using nixpkgs.firefox).
Hotlinking directly to webp files also recreates the issue. That should narrow it down a bit. [edit: I guess these links expire after some time, but its just the url to an animated youtube thumbnail]
Also works on firefox-bin 94.0.1 (master is on 94.0).
Seeing crash locally as well on and . I bisected down to (had to apply to avoid build failures). It is a merge commit with the following conflict resolution:
While at it how does one get meaningful debug symbols out of firefox? is very sad: I tried patching in the below, but got no symbols: Is there a generic way to get the symbols? Or maybe it's a good opportunity to add them to specifically?
I tried reverting , still broken. Worked when 94.0.1 was merged in .
Yeah, I have no idea on how to accomplish that either. And having that could be really helpful :+1:
I can confirm this occurs when mousing over YouTube video link/thumbnail pairs in either the main page, search results or video sidebar (on Firefox 94.0.1). Not only that but doesn't exist at all, which probably means the crash reporting feature is entirely disabled for nixpkgs Firefox?
With the stdenv patch, does ff work on both parents of the merge commit but not the commit itself?
we have crashreporter turned off by default for some reason
its been that way since (2008) we should set it to
Crash report: https://crash-
correct. Re-tested again just in case: ^0: - crash ^1: - ok ^2: - ok ^3: <invalid, only 2 parentsNote that these two branches contain about 2 weeks of commits. One of them is a update, another is an update. This merge mixes both together and firefox does not seem to work. is a full picture of all the commits involved. Anecdotally I tried to disable lto with and got working (but I suspect it also flips to in that case). Would be nice if controlled just aspect and not the rest of toolchain.
Although using is possible for LTO ultimately it complicates the expression and deviates from upstream. When I implemented support for LTO, I think it was agreed upon that we should try to follow upstream as close as possible. Hence enforcing and . The reduced maintenance burden of having to test more configurations was also a plus. That being said it would be nice if someone wants to take on that burden and expand the LTO support to be more general (and maintain it). The end goal was to actually change to build to using too but allow the native system linker. I never got around to implementing that. The reasoning being upstream tests vigorously against . This is speculation on my part but I think a point of interest here is Firefox now builds against instead of . Building with was never a requirement for LTO but a side effect of the old stdenv. At the time did not have a proper nixpkgs wrapper script and was unable to be used outside of it. (On a side note, for some reason had issues during linking with not being configured to pull in LLVM's hence the workaround. It can be removed now since is being used.) reports (about:buildconfig) being built with LLVM 12 and rustc 1.55 so this might be a new bug introduced with LLVM 13 or the newer rustc. A definitive way to test if it is a bug in the switch to would be keeping the same firefox version and having applied (so is used) but change the underlying LLVM and rustc versions to 12 and 1.55 respectively. If the crash goes away then it is tied to the LLVM and rustc version if not then something wrong is happening when using .
I created a upstream bug 3 days ago, including stack backtrace with symbols. The crash function is in . Disabling webp () can mitigate but it of course quite hurt. :disappointed: If anyone gets more information, please also post in the bug thread. BTW: Enabling debug symbols need to set configure flags and set . won't work due to .
It is mentioned in that bug report that directly opening links canot reproduce the crash. I actually had the opposite experience. I was able to recreate the crash by directly opening a webp file, although it's not 100% consistent. I also stumbled across this other URL that crashes firefox, this one is a PNG. If I right-click this URL and "Open in new window" the tab will crash about 50% of the time. Curiously, this URL seems unaffected, despite the resulting file being hash-identical. !
I just now noticed that the above image is being served with a content-type, so looks like its still webp-specific, even though no webp content is being actually rendered.
I cannot reproduce with that URL at all after tens of tries. This DOES crash me sometimes. And note that the URL actually responds a WEBP image despite it contains , maybe due to HTTP fields. You can confirm it by the tab title (once you don't crash) or download and check with . This is also fine for me. It's more complex than I think. I'll guess it might be an index-out-of-bound or other kind of heap corruption? Could you post about this in my bugzilla report?
Can you share exact change needed? Here is my non-working example of enabling the symbols:
Yeah, whatever optimization tricks is doing here is just confusing things. I'm going to ignore those results for now. I was able to create a very small poc for the bug that works reliably with the same image, though. (Also posted in the bugzilla thread)
For how to build with debug symbols, see I'm still working on this issue now and I'll make a PR about that later. Note that you need to follow and set environment before starting or .
This is happening for me.
See
the in the first post is a typo, right? If I read it right, we can keep stable nixpkgs as it is, thanks to using LLVM 12 for firefox.
Yes, updated.

gappsWrapperArgs+=(--argv0 "$out/bin/.${binaryName}-wrapped") ''; <ins> # Workaround: The separateDebugInfo hook skips artifacts whose build ID's length is not 40. # But we got 16-length build ID here. The function body is mainly copied from pkgs/build-support/setup-hooks/separate-debug-info.sh # Remove it when PR #146275 is merged. preFixup = lib.optionalString enableDebugSymbols '' _separateDebugInfo() { [ -e "$prefix" ] || return 0 local dst="''${debug:-$out}" if [ "$prefix" = "$dst" ]; then return 0; fi dst="$dst/lib/debug/.build-id" # Find executables and dynamic libraries. local i while IFS= read -r -d $'0' i; do if ! isELF "$i"; then continue; fi # Extract the Build ID. FIXME: there's probably a cleaner way. local id="$($READELF -n "$i" | sed 's/.*Build ID: ([0-9a-f]*).*/1/; t; d')" if [[ -z "$id" ]]; then echo "could not find build ID of $i, skipping" >&2 continue fi # Extract the debug info. header "separating debug info from $i (build ID $id)" mkdir -p "$dst/''${id:0:2}" $OBJCOPY --only-keep-debug "$i" "$dst/''${id:0:2}/''${id:2}.debug" $STRIP --strip-debug "$i" # Also a create a symlink <original-name>.debug. ln -sfn ".build-id/''${id:0:2}/''${id:2}.debug" "$dst/../$(basename "$i")" done < <(find "$prefix" -type f -print0) } ''; </ins> doInstallCheck = true; installCheckPhase = '' # Some basic testing


Question:
The runuser command from utillinux doesn't work. This is apparently a PAM issue. Original message on the mailing list: System: 16.09pre79463. (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: 15.09.505.
The util-linux (2.27.1-6ubuntu3) package in ubuntu xenial ships with the following pam.d config:
Both files are shipped by and respectively in the original package source. It should be possible to integrate them in our own package. Fetch and unpack.
The following line in the NixOS config appears to solve the problem. But it would be nice to have it fixed in the package itself. Also I know next to nothing about pam so I might be doing something very wrong.

{ stdenv, fetchurl, gmp }: stdenv.mkDerivation rec { <del> name = "ikarus-0.0.3"; </del> <ins> version = "0.0.3"; name = "ikarus-${version}"; </ins> src = fetchurl { <del> url = "http://ikarus-scheme.org/${name}.tar.gz"; </del> <ins> url = "http://launchpad.net/ikarus/0.0/${version}/+download/${name}.tar.gz"; </ins> sha256 = "0d4vqwqfnj39l0gar2di021kcf6bfpkc6g40yapkmxm6sxpdcvjv"; };


Question:
A clear and concise description of what the bug is. Steps to reproduce the behavior: -p nixops ... ... it builds! error: builder for '/nix/store/48sdc9gb26pb3prykylvy644mmsma0km-python2.7-ruamel-yaml-clib-' failed with exit code 1; <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Builds on linux thanks to .
still fails:
I think the issue is tracked in I do not understand what the state of nixops is. is an issue about NixOps 2.0 with all checkboxes ticked. Further down in the thread there is a link to a board called . So what's going on? Are the things in that board release blockers? Which version of nixops should normal users use today? The project does not seem to make it clear.
And even with that insecure package enabled, the fails with an import error.
NixOps 1 is effectively end-of-life. That issue does not include critical usability problems present in master. To quote my response to another issue: All maintenance to the NixOps core currently happens on NixOps 2 (master / pre-release), because of the project's limited resources. NixOps 1 relies on python 2.7, so maintaining it is not feasible with the NixOps project's limited resources. Please consider helping with maintenance and testing, or donate to This fund currently supports reviews and fixes on master. Donations greatly increase our ability to get things merged and work towards a functional NixOps 2 release.
Is there a current way to get oneself an overview of what's working in NixOps 2 master, and what isn't? Is it I would like to contribute testing it, but need to know: what the migration path from nixops 1 is (can I continue to use my existing state files?) whether there are dangerous unaddressed issues (will it wipe my infrastructure?) if there are key unsupported parts that nixops 1 has (Hetzner support, EC2 support, Route53 support)
Yes, this is more up to date than the previously linked issue. I'll have to refer to the issues and PRs. For the core, that's The documentation is still lacking in this regard, and some more work on the legacy state storage backend or other state storage code may need to be done, e.g. In my experience, NixOps 1 state files can be picked up by NixOps 2, but the opposite may not be true. Unlikely, but check the issues and prs of the plugins you're using. The plugins that are responsible for these parts should continue to support whatever those parts used to support, and they are available. IIRC we have two plugins for Hetzner now, one using a newer API. I have not worked on any hetzner related code.
don't you dare.
The build passes, if you permit that insecurity, now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

sha256 = "1mqspsn6bf3ibvih1zna2glkg8iw7vy5zg9gzg0d1m8zcndk2c48"; }; <del> checkInputs = [ pytestCheckHook pytest-benchmark enum34 numpy arrow ruamel-yaml ]; </del> <ins> checkInputs = [ pytestCheckHook pytest-benchmark enum34 numpy ]; </ins> <del> disabledTests = lib.optionals stdenv.isDarwin [ "test_multiprocessing" ]; </del> <ins> # these have dependencies that are broken on Python 2 disabledTestPaths = [ "tests/gallery/test_gallery.py" "tests/test_benchmarks.py" "tests/test_compiler.py" ]; disabledTests = [ "test_timestamp" ] ++ lib.optionals stdenv.isDarwin [ "test_multiprocessing" ]; </ins> pytestFlagsArray = [ "--benchmark-disable" ];


Question:
A clear and concise description of what the bug is. Steps to reproduce the behavior: -p nixops ... ... it builds! error: builder for '/nix/store/48sdc9gb26pb3prykylvy644mmsma0km-python2.7-ruamel-yaml-clib-' failed with exit code 1; <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Builds on linux thanks to .
still fails:
I think the issue is tracked in I do not understand what the state of nixops is. is an issue about NixOps 2.0 with all checkboxes ticked. Further down in the thread there is a link to a board called . So what's going on? Are the things in that board release blockers? Which version of nixops should normal users use today? The project does not seem to make it clear.
And even with that insecure package enabled, the fails with an import error.
NixOps 1 is effectively end-of-life. That issue does not include critical usability problems present in master. To quote my response to another issue: All maintenance to the NixOps core currently happens on NixOps 2 (master / pre-release), because of the project's limited resources. NixOps 1 relies on python 2.7, so maintaining it is not feasible with the NixOps project's limited resources. Please consider helping with maintenance and testing, or donate to This fund currently supports reviews and fixes on master. Donations greatly increase our ability to get things merged and work towards a functional NixOps 2 release.
Is there a current way to get oneself an overview of what's working in NixOps 2 master, and what isn't? Is it I would like to contribute testing it, but need to know: what the migration path from nixops 1 is (can I continue to use my existing state files?) whether there are dangerous unaddressed issues (will it wipe my infrastructure?) if there are key unsupported parts that nixops 1 has (Hetzner support, EC2 support, Route53 support)
Yes, this is more up to date than the previously linked issue. I'll have to refer to the issues and PRs. For the core, that's The documentation is still lacking in this regard, and some more work on the legacy state storage backend or other state storage code may need to be done, e.g. In my experience, NixOps 1 state files can be picked up by NixOps 2, but the opposite may not be true. Unlikely, but check the issues and prs of the plugins you're using. The plugins that are responsible for these parts should continue to support whatever those parts used to support, and they are available. IIRC we have two plugins for Hetzner now, one using a newer API. I have not worked on any hetzner related code.
don't you dare.
The build passes, if you permit that insecurity, now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

{ lib , buildPythonPackage , fetchPypi <del> , flake8 , pytest_4 , pytest-expect , mock </del> , six , webencodings <ins> , mock , pytest-expect , pytestCheckHook_5 </ins> }: buildPythonPackage rec {


Question:
A clear and concise description of what the bug is. Steps to reproduce the behavior: -p nixops ... ... it builds! error: builder for '/nix/store/48sdc9gb26pb3prykylvy644mmsma0km-python2.7-ruamel-yaml-clib-' failed with exit code 1; <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Builds on linux thanks to .
still fails:
I think the issue is tracked in I do not understand what the state of nixops is. is an issue about NixOps 2.0 with all checkboxes ticked. Further down in the thread there is a link to a board called . So what's going on? Are the things in that board release blockers? Which version of nixops should normal users use today? The project does not seem to make it clear.
And even with that insecure package enabled, the fails with an import error.
NixOps 1 is effectively end-of-life. That issue does not include critical usability problems present in master. To quote my response to another issue: All maintenance to the NixOps core currently happens on NixOps 2 (master / pre-release), because of the project's limited resources. NixOps 1 relies on python 2.7, so maintaining it is not feasible with the NixOps project's limited resources. Please consider helping with maintenance and testing, or donate to This fund currently supports reviews and fixes on master. Donations greatly increase our ability to get things merged and work towards a functional NixOps 2 release.
Is there a current way to get oneself an overview of what's working in NixOps 2 master, and what isn't? Is it I would like to contribute testing it, but need to know: what the migration path from nixops 1 is (can I continue to use my existing state files?) whether there are dangerous unaddressed issues (will it wipe my infrastructure?) if there are key unsupported parts that nixops 1 has (Hetzner support, EC2 support, Route53 support)
Yes, this is more up to date than the previously linked issue. I'll have to refer to the issues and PRs. For the core, that's The documentation is still lacking in this regard, and some more work on the legacy state storage backend or other state storage code may need to be done, e.g. In my experience, NixOps 1 state files can be picked up by NixOps 2, but the opposite may not be true. Unlikely, but check the issues and prs of the plugins you're using. The plugins that are responsible for these parts should continue to support whatever those parts used to support, and they are available. IIRC we have two plugins for Hetzner now, one using a newer API. I have not worked on any hetzner related code.
don't you dare.
The build passes, if you permit that insecurity, now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

sha256 = "b2e5b40261e20f354d198eae92afc10d750afb487ed5e50f9c4eaf07c184146f"; }; <del> checkInputs = [ flake8 pytest_4 pytest-expect mock ]; </del> propagatedBuildInputs = [ <del> six webencodings </del> <ins> six webencodings </ins> ]; <del> checkPhase = '' # remove test causing error # https://github.com/html5lib/html5lib-python/issues/411 rm html5lib/tests/test_stream.py py.test ''; </del> <ins> checkInputs = [ mock pytest-expect pytestCheckHook_5 ]; </ins> meta = { homepage = "https://github.com/html5lib/html5lib-python";


Question:
A clear and concise description of what the bug is. Steps to reproduce the behavior: -p nixops ... ... it builds! error: builder for '/nix/store/48sdc9gb26pb3prykylvy644mmsma0km-python2.7-ruamel-yaml-clib-' failed with exit code 1; <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Builds on linux thanks to .
still fails:
I think the issue is tracked in I do not understand what the state of nixops is. is an issue about NixOps 2.0 with all checkboxes ticked. Further down in the thread there is a link to a board called . So what's going on? Are the things in that board release blockers? Which version of nixops should normal users use today? The project does not seem to make it clear.
And even with that insecure package enabled, the fails with an import error.
NixOps 1 is effectively end-of-life. That issue does not include critical usability problems present in master. To quote my response to another issue: All maintenance to the NixOps core currently happens on NixOps 2 (master / pre-release), because of the project's limited resources. NixOps 1 relies on python 2.7, so maintaining it is not feasible with the NixOps project's limited resources. Please consider helping with maintenance and testing, or donate to This fund currently supports reviews and fixes on master. Donations greatly increase our ability to get things merged and work towards a functional NixOps 2 release.
Is there a current way to get oneself an overview of what's working in NixOps 2 master, and what isn't? Is it I would like to contribute testing it, but need to know: what the migration path from nixops 1 is (can I continue to use my existing state files?) whether there are dangerous unaddressed issues (will it wipe my infrastructure?) if there are key unsupported parts that nixops 1 has (Hetzner support, EC2 support, Route53 support)
Yes, this is more up to date than the previously linked issue. I'll have to refer to the issues and PRs. For the core, that's The documentation is still lacking in this regard, and some more work on the legacy state storage backend or other state storage code may need to be done, e.g. In my experience, NixOps 1 state files can be picked up by NixOps 2, but the opposite may not be true. Unlikely, but check the issues and prs of the plugins you're using. The plugins that are responsible for these parts should continue to support whatever those parts used to support, and they are available. IIRC we have two plugins for Hetzner now, one using a newer API. I have not worked on any hetzner related code.
don't you dare.
The build passes, if you permit that insecurity, now.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

# it should not override the version of pytest that is used for say # Python 2. This is an ugly hack that is needed now because the hook # propagates the package. <ins> pytestCheckHook_5 = if isPy3k then self.pytestCheckHook.override { pytest = self.pytest_5; } else self.pytestCheckHook; </ins> pytestCheckHook_6_1 = if isPy3k then self.pytestCheckHook.override { pytest = self.pytest_6_1; } else


Question: Launch GNOME Music 3.18 There's no artwork at all Log: System: (Flounder) Nix version: nix-env (Nix) 1.11.2

, gmime, json_glib, avahi, tracker, itstool }: stdenv.mkDerivation rec { <del> name = "grilo-plugins-0.2.13"; </del> <ins> name = "grilo-plugins-0.2.16"; </ins> src = fetchurl { url = "mirror://gnome/sources/grilo-plugins/0.2/${name}.tar.xz"; <del> sha256 = "008jwm5ydl0k25p3d2fkcail40fj9y3qknihxb5fg941p8qlhm55"; </del> <ins> sha256 = "00sjmkzxc8w4qn4lp5yj65c4y83mwhp0zlvk11ghvpxnklgmgd40"; </ins> }; installFlags = [ "GRL_PLUGINS_DIR=$(out)/lib/grilo-0.2" ];


Question: Launch GNOME Music 3.18 There's no artwork at all Log: System: (Flounder) Nix version: nix-env (Nix) 1.11.2

, libxml2, gnome3, gobjectIntrospection, libsoup }: stdenv.mkDerivation rec { <del> name = "grilo-0.2.12"; </del> <ins> name = "grilo-0.2.14"; </ins> src = fetchurl { url = "mirror://gnome/sources/grilo/0.2/${name}.tar.xz"; <del> sha256 = "11bvc7rsrjjwz8hp67p3fn8zmywrpawrcbi3vgw8b0dwa0sndd2m"; </del> <ins> sha256 = "1k8wj8f7xfaw5hxypnmwd34li3fq8h76dacach547rvsfjhjxj3r"; </ins> }; setupHook = ./setup-hook.sh;


Question:
When is enabled, my printer is not recognized by . Initially, when the option was not enabled, my printer would immediately get recognized upon plugging in the USB, show up in the Printers section in , and printing also works fine. After enabling SANE, the printer is not recognized, but the in-built scanner gets recognized and works properly in apps like . After disabling it and running , the printer is again immediately recognized, but obviously the scanner doesn't work. Configuration: Both the printer and scanner must function and get recognized properly when the above-mentioned configuration is applied. SANE did not give any errors Error after enabling : After disabling it, the printer gets recognized: Based on commit history for the SANE and modules Printer: CANON Pixma MG 2570 Driver: CUPS+Gutenprint v5.3.4
that is extremely puzzling, as sane is enabled or disabled though an environment variable that cannot be changed by a mere nixos-rebuild switch. you need to reboot or to logout/login to effectively toggle it.
Yes. initially, in order to enable the scanning functionality, a reboot was required. But the connection to the printer was established by simply disabling the option and rebuilding
Without lookling deeper into this, are you sure it’s not just a random coincidence? Were you setting up printing and scanning in the same session? Maybe you changed something else in-between.
Just tried it again today, same results
I have the same issue.
Pretty sure it's a permission problem. With cups enabled: With sane, saned and cups enabled: After a reboot, permissions are back to the first case. I guess there's a problem with sane's udev rules. Update: Sane or saned define udev rules that change the group of printer device nodes. I've tried setting , but libusb seems to do extra permission checking beyond the device nodes, so this doesn't allow cups to print.
Nice find! Do I understand correctly that when the device is owned by lp scanning does not work and when it is owned by scanner printing does not work?
Hello! Yes. From my understanding of , generates udev rules for every "scanner" device that changes the group permissions of device nodes to "scanner". This does not work for multifunction devices, as Cups expects device nodes to be accessible via the "lp" group. I've created a quick fix for this by overriding the derivation to delete its udev rules. Note that SANE is set up for device nodes being owned by the group (seems to be implied by . I've worked around this by overriding sane backends to delete the udev rules: This is a temporary fix, but I don't know what the "proper" way to do this would be.
Ok so when the device is owned by lp, it also works with the scanner. Reading you it looks like an issue with upstream udev rules, I wonder if filing a bug upstream is warranted.
Seems to be a known issue:
Looks like is the proper solution. would you mind giving it a try? It's hard to test without affected hardware...
Turns out the command was never run, and the rules were just copied from the sane source. requires a search path to find description files. After patching via rules are indeed generated, and the owner isn't changed.
Sounds nice. Would you mind opening a PR?
I went ahead and created , due to lack of response.
this was fixed, but incorrectly, in . A fix to the fix is in , it would be nice if people affected by this can test it.
Still works for me, tested printing & scanning with the following overlay:
Closing since it sounds like some combination of and fixed this, but I'm happy to reopen if I'm misunderstanding.

in '' mkdir -p $out/etc/udev/rules.d/ <del> ./tools/sane-desc -m udev > $out/etc/udev/rules.d/49-libsane.rules ||  </del> <ins> ./tools/sane-desc -m udev+hwdb -s doc/descriptions:doc/descriptions-external > $out/etc/udev/rules.d/49-libsane.rules ||  </ins> cp tools/udev/libsane.rules $out/etc/udev/rules.d/49-libsane.rules # the created 49-libsane references /bin/sh substituteInPlace $out/etc/udev/rules.d/49-libsane.rules


Question:
unbound-full cannot be built on the unstable channel error message: Steps to reproduce the behavior: build .#unbound-full It should obviously build cc Maintainer information:
This happened in the fixupPhase, maybe we should remove lines?
I've put some information on

, withDNSTAP ? false , withTFO ? false , withRedis ? false <ins> # Avoid .lib depending on openssl.out # The build gets a little hacky, so in some cases we disable this approach. , withSlimLib ? stdenv.isLinux && !stdenv.hostPlatform.isMusl && !withDNSTAP </ins> , libnghttp2 }:


Question:
unbound-full cannot be built on the unstable channel error message: Steps to reproduce the behavior: build .#unbound-full It should obviously build cc Maintainer information:
This happened in the fixupPhase, maybe we should remove lines?
I've put some information on

--prefix PATH : ${lib.makeBinPath [ openssl ]} ''; <del> preFixup = lib.optionalString (stdenv.isLinux && !stdenv.hostPlatform.isMusl) # XXX: revisit </del> <ins> preFixup = lib.optionalString withSlimLib </ins> # Build libunbound again, but only against nettle instead of openssl. # This avoids gnutls.out -> unbound.lib -> openssl.out. <del> # There was some problem with this on Darwin; let's not complicate non-Linux. </del> '' configureFlags="$configureFlags --with-nettle=${nettle.dev} --with-libunbound-only" configurePhase


Question:
The option does not work on aarch64-linux due to See also It seems that the current issue is that does not build on aarch64-linux. Steps to reproduce the behavior: NixOS on aarch64-linux. the option. the failure. aarch64-linux support n/a See also <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
It looks like is only pulled in when : Maybe the assertion could be relaxed a bit?
Bump. Please change this so that we can at least use the guest tools in headless mode as mentioned here:
Can you submit a PR and change the assertion message? This makes sense.
or could you give a try?
Any suggestions on how to update the assertion message? Am not sure if it should also be conditional.
Can you tell me how to single pick this PR in my configuration? Define an override?
Yes. There are multiple ways to do this. So finding the simplest or easiest way will depend on your current setup. How do you define/import nixpkgs in your configuration? That'd be one way to do it. AFAIK you'd need to add the vmware- file to (), and bind a new nixpkgs reference to my branch, where you'd import that module from.
AFAICT this is also a blocker for creating a graphical ISO for :
Seems to work on aarch64 for me:
Does not seem to work for me: ! ! Rebuild: ! Assertion is in ! (Sorry for screenshots, but copy/paste does not work yet ... as it requires the vmware guest tools ... )
Any progress - I am a begginer in nixOS. So the way to learn is setup a VM But then I hit this. What are the exact steps to use this PR? This is not just a mouse issue as the previous comment not it stops cut and paste. It also shops the use of shared folders so a fix is needed for the headless case as well.
I would love to have vmware guest on aarch64 too. I'm running VMWare Fusion on my M1 macbook. I tried the above, of disabling the vmware- and adding my own with the assert modified to accept Aarch64. However it not building x11 mouse is one issue, but even with headless = true it still fails; in this case vmw_vpscsi fails in the kernel build: !
that's a module that comes with the kernel and not vmware. It looks like it's not supported under non-x86 architectures: so we should remove it from the module if not on x86
can you test ? I don't have aarch64 but this might work.
Magic. It built successfully and as soon as nixos-rebuild switch completed my X desktop resized to match my monitor (automatically). I just used my own local vmware- (disabling the system one), in which I made the two changes that are in kjeremy's PR ^ Thank you.
Could you elaborate how you did that? The furthest I got still gives me

config = mkIf cfg.enable { assertions = [ { <del> assertion = pkgs.stdenv.hostPlatform.isx86; </del> <ins> assertion = pkgs.stdenv.hostPlatform.isx86 || pkgs.stdenv.hostPlatform.isAarch64; </ins> message = "VMWare guest is not currently supported on ${pkgs.stdenv.hostPlatform.system}"; } ]; boot.initrd.availableKernelModules = [ "mptspi" ]; <del> boot.initrd.kernelModules = [ "vmw_pvscsi" ]; </del> <ins> boot.initrd.kernelModules = lib.optionals pkgs.stdenv.hostPlatform.isx86 [ "vmw_pvscsi" ]; </ins> environment.systemPackages = [ open-vm-tools ];


Question:
Get a mac with facetimehd support and the following the laptop lid the lid back (might also need to press a key) I'm running unstable and assuming its broken on 16.03 too. System: (NixOS: , Ubuntu/Fedora: , ...) 16.09pre79453. (Flounder) Nix version: (run ) nix-env (Nix) 1.11.2 Nixpkgs version: (run ) "16.09pre79453."
It is broken since since the module is using which is obsolete and can't handle compressed modules.
Can you report if fixes this?
yes switching to kmod works (only tested facetimehd). Are there plans porting this over to 16.03?
Yeah, I assume we should port it – it doesn't seem likely to break anything and it does fix some bugs.
Oh hrm. I missed this issue conversation and put in this PR: I reckon we should backport , and
This is fixed in 16.03 and master. can you close?

# TODO add plugins having various licenses, see http://www.vamp-plugins.org/download.html <del> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo, libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate, libsndfile, makeWrapper, pulseaudio, qt4, redland, rubberband, vampSDK </del> <ins> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo , libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate , libsndfile, makeWrapper, pkgconfig, pulseaudio, qt4, redland , rubberband, vampSDK </ins> }: <del> stdenv.mkDerivation { name = "sonic-visualiser-1.8"; </del> <ins> stdenv.mkDerivation rec { name = "sonic-visualiser-${version}"; version = "1.9"; </ins> src = fetchurl { <del> url = http://downloads.sourceforge.net/sv1/sonic-visualiser-1.8.tar.gz; sha256 = "16ik6q9n92wljvnqcv7hyzb9v3yp3ixxp6df9kasf53fii973dh7"; </del> <ins> url = "http://code.soundsoftware.ac.uk/attachments/download/194/${name}.tar.gz"; sha256 = "00igf7j6s8xfyxnlkbqma0yby9pknxqzy8cmh0aw95ix80cw56fq"; </ins> }; buildInputs = [ libsndfile qt4 fftw /* should be fftw3f ??*/ bzip2 librdf rubberband libsamplerate vampSDK alsaLib librdf_raptor librdf_rasqal redland <ins> pkgconfig </ins> # optional jackaudio # portaudio


Question:
Get a mac with facetimehd support and the following the laptop lid the lid back (might also need to press a key) I'm running unstable and assuming its broken on 16.03 too. System: (NixOS: , Ubuntu/Fedora: , ...) 16.09pre79453. (Flounder) Nix version: (run ) nix-env (Nix) 1.11.2 Nixpkgs version: (run ) "16.09pre79453."
It is broken since since the module is using which is obsolete and can't handle compressed modules.
Can you report if fixes this?
yes switching to kmod works (only tested facetimehd). Are there plans porting this over to 16.03?
Yeah, I assume we should port it – it doesn't seem likely to break anything and it does fix some bugs.
Oh hrm. I missed this issue conversation and put in this PR: I reckon we should backport , and
This is fixed in 16.03 and master. can you close?

description = "View and analyse contents of music audio files"; homepage = http://www.sonicvisualiser.org/; license = "GPLv2"; <del> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </del> <ins> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </ins> platforms = stdenv.lib.platforms.linux; }; }


Question:
libcanberra is not included in of thunderbird and firefox. This prevents both applications from playing gtk sounds (for instance when receiving an email on thunderbird). Steps to reproduce the behavior: any instance of firefox And in the output of strace you will see that firefox doesn't try to open the lib dir of libcanberra in the nix store. For instance on my system: libcanberra is supposed to be in the of firefox and thunderbird wrappers. AFAIU firefox and thunderbird open this library at runtime with dlopen and that's why it's not in the generated . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
You are correct. It probably should be to the wrapper. It seems is pulled in by . Not sure what it is doing or if it is needed but adding to should address . On another note, there ought to be a tool that searches Firefox's source code for all runtime shenanigans. Also the wrapper should probably be expanded so that overriding packages into is possible.
This bug still exists. Is there any idea?

++ lib.optional jackSupport libjack2 ++ lib.optional smartcardSupport opensc ++ lib.optional (cfg.speechSynthesisSupport or false) speechd <del> ++ pkcs11Modules; </del> <ins> ++ pkcs11Modules ++ gtk_modules; </ins> gtk_modules = [ libcanberra-gtk3 ]; launcherName = "${applicationName}${nameSuffix}";


Question:
Running fails with the following error: The issue is here: Before the 2.8.0 update, this line used to say So, flutter copied the cache to , which was fine. Now, however, it tries to copy the cache to , which doesn't exist, so flutter throws an error. Steps to reproduce the behavior: do any flutter project `flutter run Flutter builds the app and runs it on the device Please run and paste the result. I cannot run it because I use flakes, so it just says .
My bad, it should be fixed by
thanks!

final Uri entryUri = _fileSystem.path.toUri(asset); result.add(_Asset( -          baseDir: _fileSystem.path.join(Cache.flutterRoot!, 'bin', 'cache', 'artifacts', 'material_fonts'), <del> +          baseDir: _fileSystem.path.join(globals.fsUtils.homeDirPath!, 'bin', 'cache', 'artifacts', 'material_fonts'), </del> <ins> +          baseDir: _fileSystem.path.join(globals.fsUtils.homeDirPath!, '.cache', 'flutter', 'artifacts', 'material_fonts'), </ins> relativeUri: Uri(path: entryUri.pathSegments.last), entryUri: entryUri, package: null,


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: roon-server <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.8-850 desired version: 1.8-880 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

, icu66 , krb5 , lib <ins> , libtasn1 </ins> , makeWrapper , stdenv , openssl }: stdenv.mkDerivation rec { pname = "roon-server"; <del> version = "1.8-850"; </del> <ins> version = "1.8-880"; </ins> src = let


Question: <!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: roon-server <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.8-850 desired version: 1.8-880 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

in fetchurl { url = "http://download.roonlabs.com/builds/RoonServer_linuxx64_${urlVersion}.tar.bz2"; <del> sha256 = "sha256-NSNaL0ERYTSYn9ETjWcQiuI4hY+w/lWVOz3n9lt6O+4="; </del> <ins> sha256 = "sha256-Td3iRYGmTg8Vx9c4e4ugIIbAqhDFPax9vR2BsCIQCZA="; </ins> }; <ins> dontConfigure = true; dontBuild = true; </ins> buildInputs = [ alsa-lib freetype krb5 <ins> libtasn1 </ins> stdenv.cc.cc.lib ];


Question:
mediathekview might be affected, the latest version 13.8.1 patched the distributed log4j version As it also updated compatibility to Java 17, and no working Java 17 distribution is in 21.11 or master atm, I'm still working on how to best address this.
See PR Full update depends on updated Java 17 , manual patching might be needed in the mean time. As it is distributed as a binary and log4j is packed into the main jar, I'm a bit stumped at the moment how to approach this.
Might work
See PR for a fix

<del> { lib, stdenv, fetchurl, makeWrapper, jre }: </del> <ins> { lib, stdenv, fetchurl, makeWrapper, jre, zip }: </ins> stdenv.mkDerivation rec { version = "13.8.0";


Question:
mediathekview might be affected, the latest version 13.8.1 patched the distributed log4j version As it also updated compatibility to Java 17, and no working Java 17 distribution is in 21.11 or master atm, I'm still working on how to best address this.
See PR Full update depends on updated Java 17 , manual patching might be needed in the mean time. As it is distributed as a binary and log4j is packed into the main jar, I'm a bit stumped at the moment how to approach this.
Might work
See PR for a fix

sha256 = "0zfkwz5psv7m0881ykgqrxwjhadg39c55aj2wpy7m1jdara86c5q"; }; <del> nativeBuildInputs = [ makeWrapper ]; </del> <ins> nativeBuildInputs = [ makeWrapper zip ]; </ins> installPhase = '' runHook preInstall mkdir -p $out/{bin,lib} <ins> # log4j mitigation, see https://logging.apache.org/log4j/2.x/security.html zip -d MediathekView.jar org/apache/logging/log4j/core/lookup/JndiLookup.class </ins> install -m644 MediathekView.jar $out/lib makeWrapper ${jre}/bin/java $out/bin/mediathek


Question:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

}: buildPythonPackage rec { <del> version = "1.6.0"; </del> <ins> version = "1.6.1"; </ins> pname = "strictyaml"; disabled = isPy27; src = fetchPypi { inherit pname version; <del> sha256 = "73fa9769214a310486d7916453a09bd38b07d28a9dcbdf27719183c1d7d949f6"; </del> <ins> sha256 = "688be16ee5d1a2f94aa4abdc6d881e8e254d173d724ac88725955fe66bdb63d4"; </ins> }; postPatch = ''


Question:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

buildPythonPackage rec { pname = "tatsu"; <del> version = "5.6.1"; </del> <ins> version = "5.7.1"; </ins> src = fetchFromGitHub { owner = "neogeny"; repo = "TatSu"; rev = "v${version}"; <del> sha256 = "149ra1lwax5m1svlv4dwjfqw00lc5vwyfj6zw2v0ammmfm1b94x9"; </del> <ins> sha256 = "12ljff6l29q92625pgsg4f7xf4dz6iz1c3zdkzz188s4lnwpy8b8"; </ins> }; disabled = pythonOlder "3.8";


Question:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

buildPythonPackage rec { pname = "terminaltables"; <del> version = "3.1.0"; </del> <ins> version = "3.1.7"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "f3eb0eb92e3833972ac36796293ca0906e998dc3be91fbe1f8615b331b853b81"; </del> <ins> sha256 = "5dab2f33927c0a020b8011c81b92830ff9fd4ba701657da5d7bfdc41048360a6"; </ins> }; meta = with lib; {


Question:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

buildPythonPackage rec { pname = "textacy"; <del> version = "0.11.0"; </del> <ins> version = "0.12.0"; </ins> disabled = pythonOlder "3.7"; src = fetchPypi { inherit pname version; <del> sha256 = "sha256-d/tyTCewoERA15iBv4H2LORFzgco15fnnN1sneeGuF4="; </del> <ins> sha256 = "2c92bdd6b47305447b64e4cb6cc43c11675f021f910a8074bc8149dbf5325e5b"; </ins> }; propagatedBuildInputs = [


Question:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

buildPythonApplication rec { pname = "trytond"; <del> version = "6.2.1"; </del> <ins> version = "6.2.2"; </ins> format = "setuptools"; disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> sha256 = "418f16c45b7130555447af901639b92bb188d39f46ce7fe4dfcd941c5959ed7e"; </del> <ins> sha256 = "9494016dd8b4da5a06dccdd1afbd918248d42da9f2c19b1eb8958052c747e193"; </ins> }; # Tells the tests which database to use


Question:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

buildPythonPackage rec { pname = "types-protobuf"; <del> version = "3.18.1"; </del> <ins> version = "3.18.2"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "6696bf3cabc51dcc076e8de025c405dbdea7488c5268c2febd14527dac82c233"; </del> <ins> sha256 = "ca21dedfe7759acbeb0cd8f5c72a74ff3c409ae0c07bc1d94eff5123ac0fa23c"; </ins> }; propagatedBuildInputs = [ types-futures ];


Question:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

buildPythonPackage rec { pname = "websocket-client"; <del> version = "1.2.1"; </del> <ins> version = "1.2.2"; </ins> disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> sha256 = "8dfb715d8a992f5712fff8c843adae94e22b22a99b2c5e6b0ec4a1a981cc4e0d"; </del> <ins> sha256 = "21861f8645eb5725d1becfe86d7e7ae1a31d98b72556f9d44fcc5100976353cf"; </ins> }; propagatedBuildInputs = [


Question:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

buildPythonPackage rec { pname = "youtube-search-python"; <del> version = "1.5.2"; </del> <ins> version = "1.5.3"; </ins> disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> sha256 = "33f0d58f4803b0b2badf860cd31fb83d3f7edecdd2c01dd09cd6511abbf0e6b9"; </del> <ins> sha256 = "4bc39224d1f0915692101a7739289c41173de2eb88b445aabc7be284802b7489"; </ins> }; propagatedBuildInputs = [ httpx ];


Question:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

buildPythonPackage rec { pname = "zope-deferredimport"; <del> version = "4.3"; </del> <ins> version = "4.3.1"; </ins> src = fetchPypi { pname = "zope.deferredimport"; inherit version; <del> sha256 = "2ddef5a7ecfff132a2dd796253366ecf9748a446e30f1a0b3a636aec9d9c05c5"; </del> <ins> sha256 = "57b2345e7b5eef47efcd4f634ff16c93e4265de3dcf325afc7315ade48d909e1"; </ins> }; propagatedBuildInputs = [ zope_proxy ];


Question:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

buildPythonPackage rec { pname = "zope-hookable"; <del> version = "5.0.1"; </del> <ins> version = "5.1.0"; </ins> src = fetchPypi { pname = "zope.hookable"; inherit version; <del> sha256 = "0hc82lfr7bk53nvbxvjkibkarngyrzgfk2i6bg8wshl0ly0pdl19"; </del> <ins> sha256 = "8fc3e6cd0486c6af48e3317c299def719b57538332a194e0b3bc6a772f4faa0e"; </ins> }; checkInputs = [ zope_testing ];


Question:
However, the following input is is rejected as "*: incorrect address specification": I expected kresd to listen on fe80::1 on port 53 on the ofborg interface, as the documentation suggests should be possible. I don't mind that it is impossible, but the documentation for this option isn't correct anymore. nixos-unstable-small, rev
Well, it no longer uses systemd sockets anymore, and instead there are a few in-nix regexps that convert them. It might not be perfect. Either way, the interface spec should surely be part of the IPv6 already, i.e. – and I think that should work (the generated lua config looks OK).
Ah, I see that systemd is weird here, at least in docs. So I don't know what we'll do with it. Either shuffle it in the in-nix regexps or document as a deviation, I suppose.

# Convert systemd-style address specification to kresd config line(s). # On Nix level we don't attempt to precisely validate the address specifications. <ins> # The optional IPv6 scope spec comes *after* port, perhaps surprisingly. </ins> mkListen = kind: addr: let <del> al_v4 = builtins.match "([0-9.]+):([0-9]+)" addr; al_v6 = builtins.match "[(.+)]:([0-9]+)" addr; </del> <ins> al_v4 = builtins.match "([0-9.]+):([0-9]+)()" addr; al_v6 = builtins.match "[(.+)]:([0-9]+)(%.*|$)" addr; </ins> al_portOnly = builtins.match "([0-9]+)" addr; al = findFirst (a: a != null) (throw "services.kresd.*: incorrect address specification '${addr}'") [ al_v4 al_v6 al_portOnly ]; <del> port = last al; addrSpec = if al_portOnly == null then "'${head al}'" else "{'::', '0.0.0.0'}"; </del> <ins> port = elemAt al 1; addrSpec = if al_portOnly == null then "'${head al}${elemAt al 2}'" else "{'::', '0.0.0.0'}"; </ins> in # freebind is set for compatibility with earlier kresd services; # it could be configurable, for example. ''


Question:
However, the following input is is rejected as "*: incorrect address specification": I expected kresd to listen on fe80::1 on port 53 on the ofborg interface, as the documentation suggests should be possible. I don't mind that it is impossible, but the documentation for this option isn't correct anymore. nixos-unstable-small, rev
Well, it no longer uses systemd sockets anymore, and instead there are a few in-nix regexps that convert them. It might not be perfect. Either way, the interface spec should surely be part of the IPv6 already, i.e. – and I think that should work (the generated lua config looks OK).
Ah, I see that systemd is weird here, at least in docs. So I don't know what we'll do with it. Either shuffle it in the in-nix regexps or document as a deviation, I suppose.

<del> { lib, stdenv, fetchurl, fetchpatch </del> <ins> { lib, stdenv, fetchurl </ins> # native deps. , runCommand, pkg-config, meson, ninja, makeWrapper # build+runtime deps.


Question:
However, the following input is is rejected as "*: incorrect address specification": I expected kresd to listen on fe80::1 on port 53 on the ofborg interface, as the documentation suggests should be possible. I don't mind that it is impossible, but the documentation for this option isn't correct anymore. nixos-unstable-small, rev
Well, it no longer uses systemd sockets anymore, and instead there are a few in-nix regexps that convert them. It might not be perfect. Either way, the interface spec should surely be part of the IPv6 already, i.e. – and I think that should work (the generated lua config looks OK).
Ah, I see that systemd is weird here, at least in docs. So I don't know what we'll do with it. Either shuffle it in the in-nix regexps or document as a deviation, I suppose.

unwrapped = stdenv.mkDerivation rec { pname = "knot-resolver"; <del> version = "5.4.3"; </del> <ins> version = "5.4.4"; </ins> src = fetchurl { url = "https://secure.nic.cz/files/knot-resolver/${pname}-${version}.tar.xz"; <del> sha256 = "488729eb93190336b6bca10de0d78ecb7919f77fcab105debc0a644aa7d0a506"; </del> <ins> sha256 = "588964319e943679d391cc9c886d40ef858ecd9b33ae160023b4e2b5182b2cea"; </ins> }; outputs = [ "out" "dev" ]; <del> patches = [ (fetchpatch { # https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1237 name = "console.aws.amazon.com-fix.patch"; url = "https://gitlab.nic.cz/knot/knot-resolver/-/commit/f4dabfbec9273703.diff"; sha256 = "3J+FDwNQ6CqIGo9pSzhrQZlHX99vXFDpPOBpwpCnOxs="; }) ]; </del> # Path fixups for the NixOS service. postPatch = '' patch meson.build <<EOF


Question:
I get the following collision: What I don't understand is why this collision is happening in the first place? I'm installing this package into an empty profile!
That's a multiple-output problem. The derivation creates two of them, both containing the file. When installing into user profiles, currently the semantics is that all outputs are installed, so this creates the collision.
Vladimír Čunát writes: What's the reason for these semantics? I would expect only 'out' to get installed by default.
Well, as for build inputs, we normally want all to be available, because you need include, lib and possibly others. should know details. It hasn't been used much yet, so I suppose we still have to figure out how to do these best (and have the most usual setup as the default).
What I haven't figured out in these cases: why installing attempts to install both and .
I am getting this same error message. Fresh install of Nix 16. Could it have regressed? This happens when I run nix-env -iA nixos.openjdk but not when I dun nix-env -iA Though those both say they point to openjdk-8

stdenv.mkDerivation rec { name = "singularity-${version}"; <del> version = "2.5.1"; </del> <ins> version = "2.5.2"; </ins> enableParallelBuilding = true;


Question:
I get the following collision: What I don't understand is why this collision is happening in the first place? I'm installing this package into an empty profile!
That's a multiple-output problem. The derivation creates two of them, both containing the file. When installing into user profiles, currently the semantics is that all outputs are installed, so this creates the collision.
Vladimír Čunát writes: What's the reason for these semantics? I would expect only 'out' to get installed by default.
Well, as for build inputs, we normally want all to be available, because you need include, lib and possibly others. should know details. It hasn't been used much yet, so I suppose we still have to figure out how to do these best (and have the most usual setup as the default).
What I haven't figured out in these cases: why installing attempts to install both and .
I am getting this same error message. Fresh install of Nix 16. Could it have regressed? This happens when I run nix-env -iA nixos.openjdk but not when I dun nix-env -iA Though those both say they point to openjdk-8

owner = "singularityware"; repo = "singularity"; rev = version; <del> sha256 = "1i029qs6dfpyirhbdz0nrx2sh5fddysk4wqkjqj5m60kxs4x8a3d"; </del> <ins> sha256 = "09wv8xagr5fjfhra5vyig0f1frfp97g99baqkh4avbzpg296q933"; </ins> }; nativeBuildInputs = [ autoreconfHook makeWrapper ];


Question:
I think it should be marked as broken to avoid frustrating other people. This package is impossible to build without more than 4G address space due to linker memory exhaustion. It can be built only on 64-bit hosts (the same as Firefox). And that permanently breaks Gnome 3 on i686. It was possible to build it in the past using local modifications, though.
what modifications did you used in the past?
Only very few to some Gnome dependencies just to build Gnome itself, like . AFAIK, there were no modifications at all to webkitgtk. It just required huge swap and to free as much RAM as possible, e.g. running nix-build with only one thread. Last December I've tried to install NixOS 21.11 and it was impossible to build because of a linker exhausting all memory address space. I've tried both ld and gold. My investigations into other Linux distros revealed that they used cross-compiling tricks to build 32-bit webkitgtk on 64-bit host. I've spent a week before giving up. Right now I'm using only x86_64 arch because of that issue. I suppose it's impossible to fix on native 32-bit host just like Firefox.
I tried different configurations and was able to complete the building without any memory issue by setting separateDebugInfo to false.
I will now try to build firefox. Edit: it is markerd as broken on 32 bits.
Interesting. Thanks for trying this. It was very painful to experiment with different configurations as it required too many hours to build on my computer. AFAIK, Firefox had a different issue which didn't involve linker. It was probably a compiler. Do you think it's sustainable? I mean, will it still be possible to build next year? Because a year ago it didn't require that trick either. I'm quite pessimistic about browsers on 32-bit architecture as is already evident from Firefox :( Also, there were similar troubles with Haskell (Pandoc) and Qt. Considering that Hydra doesn't have most 32-bit software in a binary cache and that it's often required to set in order to build it, it's really a huge pain to install NixOS on i686 arch.
works great for me. Should we add a conditional for this derivation?

outputs = [ "out" "dev" "devdoc" ]; <del> separateDebugInfo = stdenv.isLinux; </del> <ins> # https://github.com/NixOS/nixpkgs/issues/153528 # Can't be linked within a 4GB address space. separateDebugInfo = stdenv.isLinux && !stdenv.is32bit; </ins> src = fetchurl { url = "https://webkitgtk.org/releases/webkitgtk-${finalAttrs.version}.tar.xz";


Question: When attempting to add a Vim plugin, fails. It updates without error. I believe previous developers have this feature enabled in their system/user Nix configuration.

def get_current_plugins(editor: Editor) -> List[Plugin]: with CleanEnvironment(): <del> cmd = ["nix", "eval", "--impure", "--json", "--expr", editor.get_plugins] </del> <ins> cmd = ["nix", "eval", "--extra-experimental-features", "nix-command", "--impure", "--json", "--expr", editor.get_plugins] </ins> log.debug("Running command %s", cmd) out = subprocess.check_output(cmd) data = json.loads(out)


Question: A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

description = lib.mdDoc "List of plugins to install."; example = lib.literalExpression "[ pkgs.tmuxPlugins.nord ]"; }; <ins> withUtempter = mkOption { description = lib.mdDoc '' Whether to enable libutempter for tmux. This is required so that tmux can write to /var/run/utmp (which can be queried with `who` to display currently connected user sessions). Note, this will add a guid wrapper for the group utmp! ''; default = true; type = types.bool; }; </ins> }; };


Question: A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

TMUX_TMPDIR = lib.optional cfg.secureSocket ''''${XDG_RUNTIME_DIR:-"/run/user/$(id -u)"}''; }; }; <ins> security.wrappers = mkIf cfg.withUtempter { utempter = { source = "${pkgs.libutempter}/lib/utempter/utempter"; owner = "root"; group = "utmp"; setuid = false; setgid = true; }; }; </ins> }; imports = [


Question: A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

stdenv.mkDerivation rec { pname = "libutempter"; <del> version = "1.1.6"; </del> <ins> version = "1.2.1"; </ins> src = fetchurl { <del> url = "mirror://ubuntu/pool/main/libu/libutempter/libutempter_${version}.orig.tar.bz2"; sha256 = "15y3xbgznjxnfmix4xg3bwmqdvghdw7slbhazb0ybmyf65gmd65q"; </del> <ins> url = "http://ftp.altlinux.org/pub/people/ldv/utempter/libutempter-${version}.tar.gz"; sha256 = "sha256-ln/vNy85HeUBhDrYdXDGz12r2WUfAPF4MJD7wSsqNMs="; </ins> }; buildInputs = [ glib ]; patches = [ ./exec_path.patch ]; <ins> patchFlags = [ "-p2" ]; </ins> prePatch = '' substituteInPlace Makefile --replace 2711 0711 '';


Question: A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

]; meta = { <ins> homepage = "https://github.com/altlinux/libutempter"; </ins> description = "Interface for terminal emulators such as screen and xterm to record user sessions to utmp and wtmp files"; longDescription = '' The bundled utempter binary must be able to run as a user belonging to group utmp.


Question: A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

<del> diff -ur libutempter-1.1.6/iface.c libutempter-1.1.6.patched/iface.c --- libutempter-1.1.6/iface.c	2010-11-04 18:14:53.000000000 +0100 +++ libutempter-1.1.6.patched/iface.c	2018-06-06 15:09:11.417755549 +0200 @@ -60,9 +60,9 @@ </del> <ins> diff --git a/libutempter/iface.c b/libutempter/iface.c index 37c74a8..6f44c9a 100644 --- a/libutempter/iface.c +++ b/libutempter/iface.c @@ -43,7 +43,7 @@ __result; })) #endif -#define UTEMPTER_DEFAULT_PATHNAME	LIBEXECDIR "/utempter/utempter" +#define UTEMPTER_DEFAULT_PATHNAME	"utempter" static const char *utempter_pathname; static int saved_fd = -1; @@ -57,8 +57,8 @@ do_child(int master_fd, const char *path, char *const *argv) </ins> _exit(EXIT_FAILURE); } -	execv(path, argv); <ins> -	print_dbg("execv: %s", strerror(errno)); </ins> +	execvp(path, argv); <del> #ifdef	UTEMPTER_DEBUG -	fprintf(stderr, "libutempter: execv: %sn", strerror(errno)); +	fprintf(stderr, "libutempter: execvp: %sn", strerror(errno)); #endif </del> <ins> +	print_dbg("execvp: %s", strerror(errno)); </ins> <del> while (EACCES == errno) @@ -79,7 +79,7 @@ </del> <ins> while (EACCES == errno) { /* try saved group ID */ @@ -73,7 +73,7 @@ do_child(int master_fd, const char *path, char *const *argv) </ins> if (setgid(sgid)) break;


Question: A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

+		(void) execvp(path, argv); break; } <del> Only in libutempter-1.1.6.patched: result </del>


Question: A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

, pkg-config , withSystemd ? stdenv.isLinux && !stdenv.hostPlatform.isStatic, systemd , utf8proc <ins> , withUtempter ? stdenv.isLinux && !stdenv.hostPlatform.isMusl, libutempter </ins> }: let


Question: A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

ncurses libevent ] ++ lib.optionals withSystemd [ systemd ] <del> ++ lib.optionals stdenv.isDarwin [ utf8proc ]; </del> <ins> ++ lib.optionals stdenv.isDarwin [ utf8proc ] ++ lib.optionals withUtempter [ libutempter ]; </ins> configureFlags = [ "--sysconfdir=/etc" "--localstatedir=/var" ] ++ lib.optionals withSystemd [ "--enable-systemd" ] <ins> ++ lib.optionals withUtempter [ "--enable-utempter" ] </ins> ++ lib.optionals stdenv.isDarwin [ "--enable-utf8proc" ]; enableParallelBuilding = true;


Question: A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

patches = [ ./ssh_path.patch ./mosh-client_path.patch <del> ./utempter_path.patch </del> # Fix build with bash-completion 2.10 ./bash_completion_datadir.patch ];


Question: A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.

<del> diff -ur mosh-1.3.2/src/frontend/mosh-server.cc mosh-1.3.2.patched/src/frontend/mosh-server.cc --- mosh-1.3.2/src/frontend/mosh-server.cc	2017-07-22 23:14:53.000000000 +0200 +++ mosh-1.3.2.patched/src/frontend/mosh-server.cc	2018-06-06 10:45:50.725352804 +0200 @@ -351,6 +351,10 @@ } } +#ifdef HAVE_UTEMPTER +    utempter_set_helper( "utempter" ); +#endif + try { return run_server( desired_ip, desired_port, command_path, command_argv, colors, verbose, with_motd ); } catch ( const Network::NetworkException &e ) { </del>


Question:
I'm trying to start the service fusionInventory but it fails with the same error as , running the system command in a terminal also trigger the issue. Steps to reproduce the behavior: part in , this is the minimum to have fusioNInventory to start, the server doesn't need to be real, it fails before trying that. I have a real setup that also fail with the same error, I tried this one to be sure it's reproducible by everyone. note that this command line without works: the service is running fine
Solved in after debug with upstream

cp -r bin $out cp -r lib $out <ins> cp -r share $out </ins> for cur in $out/bin/*; do if [ -x "$cur" ]; then


Question:
After updating to the latest NixOS unstable channel, when running , the process will fail when building fcitx-libpinyin. Can repro this in a fresh installed NixOS using , adding the following lines: channel: : process will fail when building .....-fcitx-libpinyin- with exit code 2. The rebuild process should succeed without failure. !
Updating to 0.5.4 seems to fix it:

stdenv.mkDerivation rec { pname = "fcitx-libpinyin"; <del> version = "0.5.3"; </del> <ins> version = "0.5.4"; </ins> src = fetchurl { url = "http://download.fcitx-im.org/fcitx-libpinyin/${pname}-${version}.tar.xz"; <del> sha256 = "196c229ckib3xvafkk4n3n3jk9rpksfcjsbbwka6a9k2f34qrjj6"; </del> <ins> sha256 = "1wvsc21imbgq3chlxfw4aycmkb2vi1bkjj9frvhga2m5b5pq82k5"; </ins> }; nativeBuildInputs = [ cmake pkg-config  ];


Question:
Blender 2.93.5 Hallo When I start Blender now and set under “Render Properties” → “Cycles” Blender crashes completely. Also when I go to “Edit” → “Preferences” → “System” Blender crashes immediately with this Error: What does that tell me now? My GPU configuration in the clinfo: nix run -c nix-info -m:
I think this might be the same issue as described in

, zlib , debugVersion ? false , enableManpages ? false <del> , enableSharedLibraries ? !stdenv.hostPlatform.isStatic </del> <ins> , enableSharedLibraries ? false </ins> , version , src


Question:
Blender 2.93.5 Hallo When I start Blender now and set under “Render Properties” → “Cycles” Blender crashes completely. Also when I go to “Edit” → “Preferences” → “System” Blender crashes immediately with this Error: What does that tell me now? My GPU configuration in the clinfo: nix run -c nix-info -m:
I think this might be the same issue as described in

"-DSPHINX_WARNINGS_AS_ERRORS=OFF" ]; <del> postPatch = '' </del> <ins> postPatch = lib.optional enableSharedLibraries '' </ins> substitute '${./outputs.patch}' ./outputs.patch --subst-var lib patch -p1 < ./outputs.patch '';


Question:
Blender 2.93.5 Hallo When I start Blender now and set under “Render Properties” → “Cycles” Blender crashes completely. Also when I go to “Edit” → “Preferences” → “System” Blender crashes immediately with this Error: What does that tell me now? My GPU configuration in the clinfo: nix run -c nix-info -m:
I think this might be the same issue as described in

"-DLLVM_TARGETS_TO_BUILD="AMDGPU;X86"" ]; <del> # The comgr build tends to link against the static LLVM libraries # *and* the dynamic library. Linking against both causes errors # about command line options being registered twice. This patch # removes the static library linking. patchPhase = '' sed -e '/^llvm_map_components_to_libnames/,/[[:space:]]*Symbolize)/d'  -i CMakeLists.txt ''; </del> passthru.updateScript = writeScript "update.sh" '' #!/usr/bin/env nix-shell #!nix-shell -i bash -p curl jq common-updater-scripts


Question:
I found a disappointing issue with NixOS on AWS EC2 - absence of support for Enhanced Networking (SRI/OV) out of box. See docs at Here are separate issues: is outdated on 16.03 (less then recommended 2.14). Amazon Linux AMI is better then NixOS here amis are built without --sriov flag. Because of 1) this makes starting spot instances with --sriov trickier As I'm not an expert in AMI creating, instance management or kernel module packaging, I won't do pull requests on this topic. But I'd like to share some success with others. Here is the ixgbevf-3.1.2 kernel module package. it And here is extract from config to enable this module: My instance started and ssh works. Now I have this: Ping
Thanks, I wasn't aware of Enhanced Networking. I'll look into it.
Added the driver to the Amazon config: , . Will need to rebuild the AMIs though (and make NixOps enable Enhanced Networking automatically), and add the driver for instances.

# TODO add plugins having various licenses, see http://www.vamp-plugins.org/download.html <del> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo, libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate, libsndfile, makeWrapper, pulseaudio, qt4, redland, rubberband, vampSDK </del> <ins> { stdenv, fetchurl, alsaLib, bzip2, fftw, jackaudio, libX11, liblo , libmad, libogg, librdf, librdf_raptor, librdf_rasqal, libsamplerate , libsndfile, makeWrapper, pkgconfig, pulseaudio, qt4, redland , rubberband, vampSDK </ins> }: <del> stdenv.mkDerivation { name = "sonic-visualiser-1.8"; </del> <ins> stdenv.mkDerivation rec { name = "sonic-visualiser-${version}"; version = "1.9"; </ins> src = fetchurl { <del> url = http://downloads.sourceforge.net/sv1/sonic-visualiser-1.8.tar.gz; sha256 = "16ik6q9n92wljvnqcv7hyzb9v3yp3ixxp6df9kasf53fii973dh7"; </del> <ins> url = "http://code.soundsoftware.ac.uk/attachments/download/194/${name}.tar.gz"; sha256 = "00igf7j6s8xfyxnlkbqma0yby9pknxqzy8cmh0aw95ix80cw56fq"; </ins> }; buildInputs = [ libsndfile qt4 fftw /* should be fftw3f ??*/ bzip2 librdf rubberband libsamplerate vampSDK alsaLib librdf_raptor librdf_rasqal redland <ins> pkgconfig </ins> # optional jackaudio # portaudio


Question:
I found a disappointing issue with NixOS on AWS EC2 - absence of support for Enhanced Networking (SRI/OV) out of box. See docs at Here are separate issues: is outdated on 16.03 (less then recommended 2.14). Amazon Linux AMI is better then NixOS here amis are built without --sriov flag. Because of 1) this makes starting spot instances with --sriov trickier As I'm not an expert in AMI creating, instance management or kernel module packaging, I won't do pull requests on this topic. But I'd like to share some success with others. Here is the ixgbevf-3.1.2 kernel module package. it And here is extract from config to enable this module: My instance started and ssh works. Now I have this: Ping
Thanks, I wasn't aware of Enhanced Networking. I'll look into it.
Added the driver to the Amazon config: , . Will need to rebuild the AMIs though (and make NixOps enable Enhanced Networking automatically), and add the driver for instances.

description = "View and analyse contents of music audio files"; homepage = http://www.sonicvisualiser.org/; license = "GPLv2"; <del> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </del> <ins> maintainers = [ stdenv.lib.maintainers.marcweber stdenv.lib.maintainers.goibhniu ]; </ins> platforms = stdenv.lib.platforms.linux; }; }


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

<ins> diff --git a/setup.cfg b/setup.cfg new file mode 100644 index 0000000..6f81985 --- /dev/null +++ b/setup.cfg @@ -0,0 +1,2 @@ +[directories] +basedirlist = . </ins>


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

, enableGhostscript ? false, ghostscript ? null, gtk3 , enableGtk2 ? false, pygtk ? null, gobjectIntrospection , enableGtk3 ? false, cairo <ins> , enableTk ? false, tcl ? null, tk ? null, tkinter ? null, libX11 ? null </ins> , Cocoa, Foundation, CoreData, cf-private, libobjc, libcxx }: assert enableGhostscript -> ghostscript != null; assert enableGtk2 -> pygtk != null; <ins> assert enableTk -> (tcl != null) && (tk != null) && (tkinter != null) && (libX11 != null) ; </ins> buildPythonPackage rec { name = "matplotlib-${version}";


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

libpng pkgconfig mock pytz ] ++ stdenv.lib.optional enableGtk2 pygtk <del> ++ stdenv.lib.optionals enableGtk3 [ cairo pycairo gtk3 gobjectIntrospection pygobject3 ]; </del> <ins> ++ stdenv.lib.optionals enableGtk3 [ cairo pycairo gtk3 gobjectIntrospection pygobject3 ] ++ stdenv.lib.optionals enableTk [ tcl tk tkinter libX11 ]; </ins> <del> patches = stdenv.lib.optionals stdenv.isDarwin [ ./darwin-stdenv.patch ]; </del> <ins> patches = [ ./basedirlist.patch ] ++ stdenv.lib.optionals stdenv.isDarwin [ ./darwin-stdenv.patch ]; # Matplotlib tries to find Tcl/Tk by opening a Tk window and asking the # corresponding interpreter object for its library paths. This fails if # `$DISPLAY` is not set. The fallback option assumes that Tcl/Tk are both # installed under the same path which is not true in Nix. # With the following patch we just hard-code these paths into the install # script. postPatch = let inherit (stdenv.lib.strings) substring; tcl_tk_cache = ''"${tk}/lib", "${tcl}/lib", "${substring 0 3 tk.version}"''; in stdenv.lib.optionalString enableTk "sed -i '/self.tcl_tk_cache = None/s|None|${tcl_tk_cache}|' setupext.py"; </ins> checkPhase = '' ${python.interpreter} tests.py


Question: I would like to use the following option in in : When running the command I get following error: This is because are appended after the option. It would be better if we switch the order of these. Steps to reproduce the behavior: following configuration to execute the command will fail with following error: The program should be exectued with accepting all

then value else { executable = value; profile = null; extraArgs = []; }; args = lib.escapeShellArgs ( <del> (optional (opts.profile != null) "--profile=${toString opts.profile}") ++ opts.extraArgs </del> <ins> opts.extraArgs ++ (optional (opts.profile != null) "--profile=${toString opts.profile}") </ins> ); in ''


Question:
, CVSSv3=9.1 (nixos-21.11, nixos-unstable) CVSSv3=9.1 (nixos-21.11, nixos-unstable) CVSSv3=7.5 (nixos-21.11, nixos-unstable) An issue was discovered in the DNS proxy in Connman through 1.40. The TCP server reply implementation lacks a check for the presence of sufficient Header Data, leading to an out-of-bounds read. An issue was discovered in the DNS proxy in Connman through 1.40. forwarddnsreply mishandles a strnlen call, leading to an out-of-bounds read. An issue was discovered in the DNS proxy in Connman through 1.40. The TCP server reply implementation has an infinite loop if no data is received. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc
Unstable - 11 -

stdenv.mkDerivation rec { pname = "connman"; <del> version = "1.40"; </del> <ins> version = "1.41"; </ins> src = fetchurl { url = "mirror://kernel/linux/network/connman/${pname}-${version}.tar.xz"; <del> sha256 = "sha256-GleufOI0qjoXRKrDvlwhIdmNzpmUQO+KucxO39XtyxI="; </del> <ins> sha256 = "sha256-eftA9P3VUwxFqo5ZL7Froj02dPOpjPELiaZXbxmN5Yk="; </ins> }; patches = lib.optionals stdenv.hostPlatform.isMusl [


Question:
, CVSSv3=7.8 (nixos-21.11, nixos-unstable) CVSSv3=6.5 (nixos-21.11, nixos-unstable) CVSSv3=5.5 (nixos-21.11, nixos-unstable) CVSSv3=5.5 (nixos-21.11, nixos-unstable) CVSSv3=5.5 (nixos-21.11, nixos-unstable) There is an Assertion `scalinglistpredmatrixiddelta==1' failed at in libde265 v1.0.8 when decoding file, which allows attackers to cause a Denial of Service (DoS) by running the application with a crafted file or possibly have unspecified other impact. An Incorrect Access Control vulnerability exists in libde265 v1.0.8 due to a SEGV in An issue was discovered in libde265 v1.0.8.There is a Heap-use-after-free in intrapred.h when decoding file using . A stack-buffer-overflow exists in libde265 v1.0.8 via fallback- in function putepelhvfallback when running program . An issue has been found in libde265 v1.0.8 due to incorrect access control. A SEGV caused by a READ memory access in function derive_boundaryStrength of has occurred. The vulnerability causes a segmentation fault and application crash, which leads to remote denial of service. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc
See

<del> { lib, stdenv, fetchFromGitHub, fetchpatch, autoreconfHook, pkg-config }: </del> <ins> { lib, stdenv, fetchFromGitHub, autoreconfHook, pkg-config }: </ins> stdenv.mkDerivation rec { <del> version = "1.0.8"; </del> <ins> version = "1.0.9"; </ins> pname = "libde265"; src = fetchFromGitHub { owner = "strukturag"; repo = "libde265"; rev = "v${version}"; <del> sha256 = "1dzflqbk248lz5ws0ni5acmf32b3rmnq5gsfaz7691qqjxkl1zml"; </del> <ins> sha256 = "sha256-OpiQapppuKCR27tIG5OW+KiNMP9ysv7CaobiBOW6VUI="; </ins> }; <del> patches = [ (fetchpatch { name = "CVE-2022-1253.patch"; url = "https://github.com/strukturag/libde265/commit/8e89fe0e175d2870c39486fdd09250b230ec10b8.patch"; sha256 = "sha256-F1BOWFx9oXR2trM22atyD3AJ5x6vVfURQ/PTlYP2Ibg="; }) ]; </del> nativeBuildInputs = [ autoreconfHook pkg-config ]; enableParallelBuilding = true;


Question:
, CVSSv3=6.5 (nixos-21.11, nixos-unstable) A NULL pointer dereference issue was found in the block mirror layer of QEMU in versions prior to 6.2.0. The pointer is dereferenced in mirrorwaiton_conflicts() without ensuring that it's not NULL. A malicious unprivileged user within the guest could use this flaw to crash the QEMU process on the host when writing data reaches the threshold of mirroring node. Scanned versions: nixos-21.11: ; nixos-unstable: . Cc Cc
This is fixed on master since we have QEMU 6.2.0. It's not included in 6.1.1 though, so needs to be fixed on stable. Probably after since it'd be a merge conflict.

sha256 = "09xz06g57wxbacic617pq9c0qb7nly42gif0raplldn5lw964xl2"; revert = true; }) <ins> (fetchpatch { name = "CVE-2021-4145.patch"; url = "https://gitlab.com/qemu-project/qemu/-/commit/66fed30c9cd11854fc878a4eceb507e915d7c9cd.patch"; sha256 = "10za2nag51y4fhc8z7fzw3dfhj37zx8rwg0xcmw5kzmb0gyvvz70"; }) </ins> ] ++ lib.optional nixosTestRunner ./force-uid0-on-9p.patch ++ lib.optionals stdenv.hostPlatform.isMusl [ ./sigrtminmax.patch


Question:
I want to use (providing ) for it's Debug Adapter support. Particularly it seems like Helix can utilize it with some early debugging support. However, it doesn't seem to work. After adding that to my nix shell, and entering it, and trying to run it, I get:
cc: since I'm running your latest PR bumping this.
I suspect that vscode-lldb's fork of lldb needs to be updated?
Oh yeah, that would be because the adapter is patched-inline in the extension process and the unwrapped, useless, adapter is passed thru instead.
I have some work that fixes this: just uses regular lldb now, we can drop the "fork" with the "rust-enabled" check tries to exec-itself in certain scenarios and must be patched so that it properly calls its wrapped version But most of all, it seems like is ... just built as part of already. I'm not even sure if there's a huge point in bothering with and in general. I really wish this were less messy. was a hassle to figure out, has a bad name, the repo that you find online is old and says darwin-only. yeesh.
i got hit by this, but now it says
Actually only resolves the issue. The original issue of missing still exists somewhat. Yet a working binary can be found after that PR at Help is wanted to resolve the path issue of the adapter sub package :smilingfacewith_tear:
why was this closed? I don't think it's fixed.

"--bin=codelldb" ]; <ins> postFixup = '' mkdir -p $out/share # codelldb expects libcodelldb.so to be in the same # directory as the executable, and can't find it in $out/lib. # To make codelldb executable as a standalone, # we put all files in $out/share, and then wrap the binary in $out/bin. mv $out/bin/* $out/share cp $out/lib/* $out/share ln -s ${lldb.lib} $out/lldb makeWrapper $out/share/codelldb $out/bin/codelldb  --set-default LLDB_DEBUGSERVER_PATH "${lldb.out}/bin/lldb-server" ''; </ins> patches = [ ./adapter-output-shared_object.patch ]; # Tests are linked to liblldb but it is not available here.