Question:
name: current version: desired version: latest version: maintainers: Please tag this issue in your PR.
You'll have to package pydeck as well
Here's my hack to get things working: And WIP:
I can PR this for you if you accept maintaining the dependency.
ping

<del> {   lib, buildPythonApplication, fetchPypi , altair, astor, base58, blinker, boto3, botocore, click, enum-compat , future, pillow, protobuf, requests, toml, tornado_5, tzlocal, validators, watchdog , jinja2, setuptools </del> <ins> { # Nix lib, buildPythonApplication, fetchPypi, # Build inputs altair, astor, base58, blinker, boto3, botocore, click, cachetools, enum-compat, future, GitPython, jinja2, pillow, pyarrow, pydeck, pympler, protobuf, requests, setuptools, toml, tornado, tzlocal, validators, watchdog, </ins> }: <del> buildPythonApplication rec { </del> <ins> let click_7 = click.overridePythonAttrs(old: rec { version = "7.1.2"; src = old.src.override { inherit version; sha256 = "d2b5255c7c6349bc1bd1e59e08cd12acbbd63ce649f2588755783aa94dfb6b1a"; }; }); in buildPythonApplication rec { </ins> pname = "streamlit"; <del> version = "0.50.2"; </del> <ins> version = "1.2.0"; </ins> format = "wheel"; # the only distribution available src = fetchPypi { inherit pname version format; <del> sha256 = "1wymv7qckafs0p2jdjlxjaf1xrhm3iyd185jkldanbb0na5n3ndz"; </del> <ins> sha256 = "1dzb68a8n8wvjppcmqdaqnh925b2dg6rywv51ac9q09zjxb6z11n"; </ins> }; propagatedBuildInputs = [ <del> altair astor base58 blinker boto3 botocore click enum-compat future pillow protobuf requests toml tornado_5 tzlocal validators watchdog jinja2 setuptools </del> <ins> altair astor base58 blinker boto3 botocore cachetools click_7 enum-compat future GitPython jinja2 pillow protobuf pyarrow pydeck pympler requests setuptools toml tornado tzlocal validators watchdog </ins> ]; postInstall = ''


Question:
name: current version: desired version: latest version: maintainers: Please tag this issue in your PR.
You'll have to package pydeck as well
Here's my hack to get things working: And WIP:
I can PR this for you if you accept maintaining the dependency.
ping

maintainers = with maintainers; [ yrashk ]; license = licenses.asl20; }; }


Question:
Describe the bug Postgres already exists as a nix package () bundled with some packages (). Postgres itself has built-in support for Python, but it needs to be enabled during the build process () via the configure flag. The current implementation of postgres in nix does not enable python support, and it also doesn't seem to perform any detection whether python support should be offered. There is already some form of conditional feature support (for example via the attribute. It could be possible to add a attribute that enables python. My knowledge of nix is clearly lacking in this regard, but I hope the idea makes sense. To Reproduce Steps to reproduce the behavior: via then use to initialize and start a server instance psql to enter the postgres instance 'create extension plpython3u;' ! Expected behavior The ability to enable the plpython3u extension. Screenshots This is a screenshot of the current configureFlags of postgres (). Somehow it should be possible to get into this list. ! Additional context I am trying to get a nix-shell working that has a postgresql12 with python support. I am not trying to get a working configuration in NixOS. It should be possible to use to explicitly add support for plpython. I am still exploring this possibility. Others have done something similar for other postgres extensions (). There is a nix pill that describes how to override packages here () and here (). However, it looks like this can get complicated (). More examples of overriding can be found here: Another approach for overriding packages is via overlays (). By including support for python in the derivation itself, it may be easier for new users to get started. attempted to add support for multicorn (), which is implemented using python (), but this doesn't use plpython3u, and is thus not directly related to this issue. Just mentioning it here for others that are trying to figure out how to get python in their database backend. The author of the following article shows how to configure postgres using : I can imagine a solution that may look like this: . Another possibility, is to have something like (see etc.). Notify maintainers Can you recommend a way to get plpython3u enabled in the nix build of postgres? Metadata Please run and paste the result. Maintainer information:
The following extract seems to work so far:
I marked this as stale due to inactivity. →
I'm interested in using this but not sure when I'd be able to pick it up.

, nukeReferences, patchelf, llvmPackages , makeRustPlatform, buildPgxExtension, cargo, rustc <ins> # PL/Python , pythonSupport ? false , python3 </ins> # detection of crypt fails when using llvm stdenv, so we add it manually # for <13 (where it got removed: https://github.com/postgres/postgres/commit/c45643d618e35ec2fe91438df15abd4f3c0d85ca) , libxcrypt


Question:
Describe the bug Postgres already exists as a nix package () bundled with some packages (). Postgres itself has built-in support for Python, but it needs to be enabled during the build process () via the configure flag. The current implementation of postgres in nix does not enable python support, and it also doesn't seem to perform any detection whether python support should be offered. There is already some form of conditional feature support (for example via the attribute. It could be possible to add a attribute that enables python. My knowledge of nix is clearly lacking in this regard, but I hope the idea makes sense. To Reproduce Steps to reproduce the behavior: via then use to initialize and start a server instance psql to enter the postgres instance 'create extension plpython3u;' ! Expected behavior The ability to enable the plpython3u extension. Screenshots This is a screenshot of the current configureFlags of postgres (). Somehow it should be possible to get into this list. ! Additional context I am trying to get a nix-shell working that has a postgresql12 with python support. I am not trying to get a working configuration in NixOS. It should be possible to use to explicitly add support for plpython. I am still exploring this possibility. Others have done something similar for other postgres extensions (). There is a nix pill that describes how to override packages here () and here (). However, it looks like this can get complicated (). More examples of overriding can be found here: Another approach for overriding packages is via overlays (). By including support for python in the derivation itself, it may be easier for new users to get started. attempted to add support for multicorn (), which is implemented using python (), but this doesn't use plpython3u, and is thus not directly related to this issue. Just mentioning it here for others that are trying to figure out how to get python in their database backend. The author of the following article shows how to configure postgres using : I can imagine a solution that may look like this: . Another possibility, is to have something like (see etc.). Notify maintainers Can you recommend a way to get plpython3u enabled in the nix build of postgres? Metadata Please run and paste the result. Maintainer information:
The following extract seems to work so far:
I marked this as stale due to inactivity. →
I'm interested in using this but not sure when I'd be able to pick it up.

++ lib.optionals lz4Enabled [ lz4 ] ++ lib.optionals zstdEnabled [ zstd ] ++ lib.optionals enableSystemd [ systemd ] <ins> ++ lib.optionals pythonSupport [ python3 ] </ins> ++ lib.optionals gssSupport [ libkrb5 ] ++ lib.optionals stdenv'.isLinux [ linux-pam ] ++ lib.optionals (!stdenv'.isDarwin) [ libossp_uuid ];


Question:
Describe the bug Postgres already exists as a nix package () bundled with some packages (). Postgres itself has built-in support for Python, but it needs to be enabled during the build process () via the configure flag. The current implementation of postgres in nix does not enable python support, and it also doesn't seem to perform any detection whether python support should be offered. There is already some form of conditional feature support (for example via the attribute. It could be possible to add a attribute that enables python. My knowledge of nix is clearly lacking in this regard, but I hope the idea makes sense. To Reproduce Steps to reproduce the behavior: via then use to initialize and start a server instance psql to enter the postgres instance 'create extension plpython3u;' ! Expected behavior The ability to enable the plpython3u extension. Screenshots This is a screenshot of the current configureFlags of postgres (). Somehow it should be possible to get into this list. ! Additional context I am trying to get a nix-shell working that has a postgresql12 with python support. I am not trying to get a working configuration in NixOS. It should be possible to use to explicitly add support for plpython. I am still exploring this possibility. Others have done something similar for other postgres extensions (). There is a nix pill that describes how to override packages here () and here (). However, it looks like this can get complicated (). More examples of overriding can be found here: Another approach for overriding packages is via overlays (). By including support for python in the derivation itself, it may be easier for new users to get started. attempted to add support for multicorn (), which is implemented using python (), but this doesn't use plpython3u, and is thus not directly related to this issue. Just mentioning it here for others that are trying to figure out how to get python in their database backend. The author of the following article shows how to configure postgres using : I can imagine a solution that may look like this: . Another possibility, is to have something like (see etc.). Notify maintainers Can you recommend a way to get plpython3u enabled in the nix build of postgres? Metadata Please run and paste the result. Maintainer information:
The following extract seems to work so far:
I marked this as stale due to inactivity. →
I'm interested in using this but not sure when I'd be able to pick it up.

] ++ lib.optionals lz4Enabled [ "--with-lz4" ] ++ lib.optionals zstdEnabled [ "--with-zstd" ] ++ lib.optionals gssSupport [ "--with-gssapi" ] <ins> ++ lib.optionals pythonSupport [ "--with-python" ] </ins> ++ lib.optionals stdenv'.hostPlatform.isRiscV [ "--disable-spinlocks" ] ++ lib.optionals jitSupport [ "--with-llvm" ] ++ lib.optionals stdenv'.isLinux [ "--with-pam" ];


Question: Describe the bug Library is not found when linking on macos. To Reproduce Execute resulting in following output: Expected behavior Deno builds without errors on macos. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(suraj): nixpkgs: Maintainer information:

, rust , rustPlatform , installShellFiles <ins> , libiconv </ins> , libobjc , Security , CoreServices


Question: Describe the bug Library is not found when linking on macos. To Reproduce Execute resulting in following output: Expected behavior Deno builds without errors on macos. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(suraj): nixpkgs: Maintainer information:

# Install completions post-install nativeBuildInputs = [ installShellFiles ]; <del> buildInputs = lib.optionals stdenv.isDarwin [ libobjc Security CoreServices Metal Foundation ]; </del> <ins> buildInputs = lib.optionals stdenv.isDarwin [ libiconv libobjc Security CoreServices Metal Foundation ]; </ins> # The rusty_v8 package will try to download a `librusty_v8.a` release at build time to our read-only filesystem # To avoid this we pre-download the file and place it in the locations it will require it in advance


Question:
Describe the bug For sandboxed builds on my mac, any python tests which ultimately import will fail with this error: To Reproduce Somewhat tricky to reproduce since it only affects downstream dependees, and a recent commit disabled the dask tests, hiding this issue. See for an example. Additional context Dask.dataframes infers an optimal chunk size using a package to get the amount of available memory and CPUs. This non-determinism breaks the build. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Metadata This is not valid since I am building from master of nixpkgs. system: host os: multi-user?: sandbox: version: channels(noah): nixpkgs: Maintainer information:
That's a clear upstream bug; apparently their value is not given.

{ lib , bokeh , buildPythonPackage <ins> , fetchpatch </ins> , fetchFromGitHub , fsspec , pytestCheckHook


Question:
Describe the bug For sandboxed builds on my mac, any python tests which ultimately import will fail with this error: To Reproduce Somewhat tricky to reproduce since it only affects downstream dependees, and a recent commit disabled the dask tests, hiding this issue. See for an example. Additional context Dask.dataframes infers an optimal chunk size using a package to get the amount of available memory and CPUs. This non-determinism breaks the build. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Metadata This is not valid since I am building from master of nixpkgs. system: host os: multi-user?: sandbox: version: channels(noah): nixpkgs: Maintainer information:
That's a clear upstream bug; apparently their value is not given.

distributed ]; <del> doCheck = false; </del> <ins> doCheck = true; </ins> checkInputs = [ pytestCheckHook


Question:
Describe the bug For sandboxed builds on my mac, any python tests which ultimately import will fail with this error: To Reproduce Somewhat tricky to reproduce since it only affects downstream dependees, and a recent commit disabled the dask tests, hiding this issue. See for an example. Additional context Dask.dataframes infers an optimal chunk size using a package to get the amount of available memory and CPUs. This non-determinism breaks the build. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Metadata This is not valid since I am building from master of nixpkgs. system: host os: multi-user?: sandbox: version: channels(noah): nixpkgs: Maintainer information:
That's a clear upstream bug; apparently their value is not given.

dontUseSetuptoolsCheck = true; <ins> patches = [ # dask dataframe cannot be imported in sandboxed builds # See https://github.com/dask/dask/pull/7601 (fetchpatch { url = "https://github.com/dask/dask/commit/9ce5b0d258cecb3ef38fd844135ad1f7ac3cea5f.patch"; sha256 = "sha256-1EVRYwAdTSEEH9jp+UOnrijzezZN3iYR6q6ieYJM3kY="; name = "fix-dask-dataframe-imports-in-sandbox.patch"; }) ]; </ins> postPatch = '' # versioneer hack to set version of github package echo "def get_versions(): return {'dirty': False, 'error': None, 'full-revisionid': None, 'version': '${version}'}" > dask/_version.py


Question:
Describe the bug For sandboxed builds on my mac, any python tests which ultimately import will fail with this error: To Reproduce Somewhat tricky to reproduce since it only affects downstream dependees, and a recent commit disabled the dask tests, hiding this issue. See for an example. Additional context Dask.dataframes infers an optimal chunk size using a package to get the amount of available memory and CPUs. This non-determinism breaks the build. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Metadata This is not valid since I am building from master of nixpkgs. system: host os: multi-user?: sandbox: version: channels(noah): nixpkgs: Maintainer information:
That's a clear upstream bug; apparently their value is not given.

disabledTests = [ "test_annotation_pack_unpack" "test_annotations_blockwise_unpack" <ins> # this test requires features of python3Packages.psutil that are # blocked in sandboxed-builds "test_auto_blocksize_csv" </ins> ]; <ins> pythonImportsCheck = [ "dask.dataframe" "dask" "dask.array" ]; </ins> meta = with lib; { description = "Minimal task scheduling abstraction"; homepage = "https://dask.org/";


Question:
Describe the bug For sandboxed builds on my mac, any python tests which ultimately import will fail with this error: To Reproduce Somewhat tricky to reproduce since it only affects downstream dependees, and a recent commit disabled the dask tests, hiding this issue. See for an example. Additional context Dask.dataframes infers an optimal chunk size using a package to get the amount of available memory and CPUs. This non-determinism breaks the build. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Metadata This is not valid since I am building from master of nixpkgs. system: host os: multi-user?: sandbox: version: channels(noah): nixpkgs: Maintainer information:
That's a clear upstream bug; apparently their value is not given.

options = { isoImage.isoName = mkOption { <del> default = "${config.isoImage.isoName}.iso"; </del> <ins> default = "${config.isoImage.isoBaseName}.iso"; </ins> description = '' Name of the generated ISO image file. '';


Question:
, CVSSv3=8.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also:

branch = "3.4.8"; sha256 = "1d0r4yja2dkkyhdwx1migq46gsrcbajiv66263a5sq5bfr9dqkch"; darwinFrameworks = [ Cocoa CoreMedia ]; <ins> knownVulnerabilities = [ "CVE-2021-30123" ]; </ins> } // args)


Question: , CVSSv3=2.7 (nixos-unstable) Scanned versions: nixos-unstable: . Cc

stdenv.mkDerivation rec { pname = "jasper"; <del> version = "2.0.28"; </del> <ins> version = "2.0.32"; </ins> src = fetchFromGitHub { owner = "jasper-software"; repo = pname; rev = "version-${version}"; <del> hash = "sha256-f3UG5w8GbwZcsFBaQN6v8kdEkKIGgizcAgaVZtKwS78="; </del> <ins> hash = "sha256-Uwgtex0MWC/pOmEr8itHMIa4wxd97c/tsTzcLgV8D0I="; </ins> }; nativeBuildInputs = [


Question: , CVSSv3=2.7 (nixos-unstable) Scanned versions: nixos-unstable: . Cc

stdenv.mkDerivation rec { pname = "libnbd"; <del> version = "1.7.5"; </del> <ins> version = "1.7.7"; </ins> src = fetchurl { url = "https://download.libguestfs.org/libnbd/${lib.versions.majorMinor version}-development/${pname}-${version}.tar.gz"; <del> sha256 = "sha256-UxQx/wnKnCB3uC9xEfq1F0l3kHAJjp9GzbeRugKyFsk="; </del> <ins> hash = "sha256-fNeu1qx+EbKitv2I8nJAmGMF5jxN2RZGPR/LJYnOjG8="; </ins> }; nativeBuildInputs = [


Question:
Describe the bug Trying to run a nautilus-python extension (syncstate-) fails with ImportError: could not import gobject (error was: ModuleNotFoundError("No module named 'gi'")) To Reproduce gnome3 and install nextcloud-client nautilus from terminal with something like Expected behavior python should find gi. Additional context I think it is part of pygobject3 which is in buildInputs therefore I think it is a problem of a wrong NIXPYTHONPATH Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I am not sure if it ever worked. The shared module links against pygobject but that still does not have to mean the gi module will be available on Python side. Maybe we need something like the following: At least until we have .
Yes this works, thank you!
hmmm I just tried with the new nautilus-python, but the nautilus python extensions still fail due to missing gi. Is there a reason that you tried to load gi in nautilus-python and not add the prefix arg as in your comment?
Did you make sure is updated? It worked for me with gsconnect extension. I chose that method because pygobject is really nautilus-python dependency, not nautilus one.
nevermind it works now (also with nextcloud), I forgot the in the overlay where I overwrote the package from master. Thanks for fixing it!

<del> { lib, stdenv </del> <ins> { stdenv , lib , substituteAll </ins> , fetchurl , pkg-config , which


Question:
Describe the bug Trying to run a nautilus-python extension (syncstate-) fails with ImportError: could not import gobject (error was: ModuleNotFoundError("No module named 'gi'")) To Reproduce gnome3 and install nextcloud-client nautilus from terminal with something like Expected behavior python should find gi. Additional context I think it is part of pygobject3 which is in buildInputs therefore I think it is a problem of a wrong NIXPYTHONPATH Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I am not sure if it ever worked. The shared module links against pygobject but that still does not have to mean the gi module will be available on Python side. Maybe we need something like the following: At least until we have .
Yes this works, thank you!
hmmm I just tried with the new nautilus-python, but the nautilus python extensions still fail due to missing gi. Is there a reason that you tried to load gi in nautilus-python and not add the prefix arg as in your comment?
Did you make sure is updated? It worked for me with gsconnect extension. I chose that method because pygobject is really nautilus-python dependency, not nautilus one.
nevermind it works now (also with nextcloud), I forgot the in the overlay where I overwrote the package from master. Thanks for fixing it!

sha256 = "161050sx3sdxqcpjkjcpf6wl4kx0jydihga7mcvrj9c2f8ly0g07"; }; <ins> patches = [ # Make PyGObject’s gi library available. (substituteAll { src = ./fix-paths.patch; pythonPaths = lib.concatMapStringsSep ", " (pkg: "'${pkg}/${python3.sitePackages}'") [ python3.pkgs.pygobject3 ]; }) ]; </ins> nativeBuildInputs = [ pkg-config which


Question:
Describe the bug Trying to run a nautilus-python extension (syncstate-) fails with ImportError: could not import gobject (error was: ModuleNotFoundError("No module named 'gi'")) To Reproduce gnome3 and install nextcloud-client nautilus from terminal with something like Expected behavior python should find gi. Additional context I think it is part of pygobject3 which is in buildInputs therefore I think it is a problem of a wrong NIXPYTHONPATH Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I am not sure if it ever worked. The shared module links against pygobject but that still does not have to mean the gi module will be available on Python side. Maybe we need something like the following: At least until we have .
Yes this works, thank you!
hmmm I just tried with the new nautilus-python, but the nautilus python extensions still fail due to missing gi. Is there a reason that you tried to load gi in nautilus-python and not add the prefix arg as in your comment?
Did you make sure is updated? It worked for me with gsconnect extension. I chose that method because pygobject is really nautilus-python dependency, not nautilus one.
nevermind it works now (also with nextcloud), I forgot the in the overlay where I overwrote the package from master. Thanks for fixing it!

<ins> diff --git a/src/nautilus-python.c b/src/nautilus-python.c index 843e3c6..466a513 100644 --- a/src/nautilus-python.c +++ b/src/nautilus-python.c @@ -184,6 +184,9 @@ nautilus_python_init_python (void) { return FALSE; } +    debug("Add PyGObject to path"); +    PyRun_SimpleString("import site;import functools; functools.reduce(lambda k, p: site.addsitedir(p, k), [@pythonPaths@], site._init_pathinfo())"); + /* import gobject */ debug("init_pygobject"); if (!np_init_pygobject()) { </ins>


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: ghc <!-- 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: desired version: <!-- 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.
Today I tried to install , but it failed at downloading : complained about hash mismatch. It seems like URL has changed.
I used the following overlay as a workaround:
Should work with .

# https://downloads.haskell.org/~ghc/8.10.2/ src = fetchurl ({ i686-linux = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-i386-deb9-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-i386-deb9-linux.tar.xz"; </ins> sha256 = "0bvwisl4w0z5z8z0da10m9sv0mhm9na2qm43qxr8zl23mn32mblx"; }; x86_64-linux = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-x86_64-deb10-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-x86_64-deb10-linux.tar.xz"; </ins> sha256 = "0chnzy9j23b2wa8clx5arwz8wnjfxyjmz9qkj548z14cqf13slcl"; }; armv7l-linux = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-armv7-deb10-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-armv7-deb10-linux.tar.xz"; </ins> sha256 = "1j41cq5d3rmlgz7hzw8f908fs79gc5mn3q5wz277lk8zdf19g75v"; }; aarch64-linux = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-aarch64-deb10-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-aarch64-deb10-linux.tar.xz"; </ins> sha256 = "14smwl3741ixnbgi0l51a7kh7xjkiannfqx15b72svky0y4l3wjw"; }; x86_64-darwin = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-x86_64-apple-darwin.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-x86_64-apple-darwin.tar.xz"; </ins> sha256 = "1hngyq14l4f950hzhh2d204ca2gfc98pc9xdasxihzqd1jq75dzd"; }; }.${stdenv.hostPlatform.system}


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: ghc <!-- 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: desired version: <!-- 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.
Today I tried to install , but it failed at downloading : complained about hash mismatch. It seems like URL has changed.
I used the following overlay as a workaround:
Should work with .

else "${lib.getLib glibc}/lib/ld-linux*"; <ins> downloadsUrl = "https://downloads.haskell.org/ghc"; </ins> in stdenv.mkDerivation rec {


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: ghc <!-- 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: desired version: <!-- 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.
Today I tried to install , but it failed at downloading : complained about hash mismatch. It seems like URL has changed.
I used the following overlay as a workaround:
Should work with .

src = fetchurl ({ i686-linux = { # Don't use the Fedora27 build (as below) because there isn't one! <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-i386-deb9-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-i386-deb9-linux.tar.xz"; </ins> sha256 = "1p2h29qghql19ajk755xa0yxkn85slbds8m9n5196ris743vkp8w"; }; x86_64-linux = { # This is the Fedora build because it links against ncurses6 where the # deb9 one links against ncurses5, see here # https://github.com/NixOS/nixpkgs/issues/85924 for a discussion <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-x86_64-fedora27-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-x86_64-fedora27-linux.tar.xz"; </ins> sha256 = "18dlqm5d028fqh6ghzn7pgjspr5smw030jjzl3kq6q1kmwzbay6g"; }; aarch64-linux = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-aarch64-ubuntu18.04-linux.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-aarch64-ubuntu18.04-linux.tar.xz"; </ins> sha256 = "11n7l2a36i5vxzzp85la2555q4m34l747g0pnmd81cp46y85hlhq"; }; x86_64-darwin = { <del> url = "http://haskell.org/ghc/dist/${version}/ghc-${version}-x86_64-apple-darwin.tar.xz"; </del> <ins> url = "${downloadsUrl}/${version}/ghc-${version}-x86_64-apple-darwin.tar.xz"; </ins> sha256 = "0s9188vhhgf23q3rjarwhbr524z6h2qga5xaaa2pma03sfqvvhfz"; }; }.${stdenv.hostPlatform.system}


Question:
nixosTests.blockbook-frontend fails to build Discovered in Refs Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Maintainer information:
cc
Tests are "fine". It's the main that's causing the issues (failing to build) and it was not working for some time now (as I've discovered also ). I did some initial debugging and broke the . I've notified upstream but I guess there's little I can do about it so it either gets fixed or we should remove the package altogether.
Hm, I suggest we mark blockbook as broken for the time being:

license = licenses.agpl3; maintainers = with maintainers; [ mmahut _1000101 ]; platforms = platforms.unix; <ins> # go dependency tecbot/gorocksdb requires rocksdb 5.x but nixpkgs has only rocksdb 6.x # issue in upstream can be tracked here: https://github.com/trezor/blockbook/issues/617 broken = true; </ins> }; }


Question: Describe the bug nextcloud default nginx config did not include the ` config see: but expires is set in Expected behavior no expires, the cache option causes problems with the usage of Deck

}; extraConfig = '' index index.php index.html /index.php$request_uri; <del> expires 1m; </del> add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none;


Question:
Describe the bug The phosh lockscreen will accept any pin. To Reproduce Steps to reproduce the behavior: phosh screen with 1 even if it isn't your pin! Expected behavior Probably use the numeric password of the user Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Solution The PAM configuration seems to be at fault. I can't PAM my way out of a paper bag, but I tried one attempt: Why ? Here's why: That doesn't explain the issue. Only a plausible fix. With this, only the user password is accepted. We should get someone who understand PAM to look at this. Metadata Ran on top of . Maintainer information:
Uh, so the problem is that does not exist, so there are no requirements enforced? Or what does our pam file for phosh look like? The better approach would likely be to add here:
Sorry, I probably misexplained a bit here: we're not using the manjaro pam bit at all. So I suspect those are not good at all. When using the manjaro bit verbatim, you just can't unlock! I guess adding to that list you linked to could do it too? If the other snippet is removed.
Ouch, that pam file is not testing for anything meaningful, so it shouldn't come as a surprise. Login works if you are not root. pamnologin is a PAM module that prevents users from logging into the system when /etc/nologin exists is designed to succeed or fail authentication based on characteristics of the account belonging to the user being authenticated. pamsecuretty is a PAM module that allows root logins only if the user is logging in on a "secure" tty, (Quoting from their individual manpages) Because we have no pam.d file.

programs.feedbackd.enable = true; <del> # https://source.puri.sm/Librem5/phosh/-/issues/303 security.pam.services.phosh = { text = '' auth    requisite       pam_nologin.so auth    required        pam_succeed_if.so user != root quiet_success auth    required        pam_securetty.so auth    requisite       pam_nologin.so ''; }; </del> <ins> security.pam.services.phosh = {}; </ins> services.gnome.core-shell.enable = true; services.gnome.core-os-services.enable = true;


Question:
Describe the bug json-glib seems to be a new transitive dependency of tracker/gtk, which the Paradox launcher needs. Somehow it isn't being pulled into the Steam container. To Reproduce Steps to reproduce the behavior: Steam a Paradox game (eg. Stellaris) to start the game Expected behavior Instead of the launcher working as usual, it doesn't launch at all. Launching it directly yields the following error: Additional context Adding json-glib to steam's fhs wrapper libraries is sufficient to start the launcher, but should it be propagated by gtk implicitly? Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
which game? I tried eu4 and CK3 and both launch fine
Stellaris. Funny that it seems to work with the others, I suppose it could be something specific to my system?
Unlikely, steam games run in a bubblewrap sandbox, so your host system doesn't matter much.

gst_all_1.gstreamer gst_all_1.gst-plugins-ugly gst_all_1.gst-plugins-base <ins> json-glib # paradox launcher (Stellaris) </ins> libdrm libxkbcommon # paradox launcher mono


Question:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by

nativeBuildInputs = [ pkgconfig gettext perl python ]; <del> propagatedBuildInputs = [ pcre zlib libffi ] ++ libiconvOrEmpty ++ libintlOrEmpty; </del> <ins> propagatedBuildInputs = [ pcre zlib libffi ] ++ optional (!stdenv.isDarwin) libiconvOrEmpty ++ libintlOrEmpty; </ins> configureFlags = optional stdenv.isDarwin "--disable-compile-warnings"


Question:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by

propagatedBuildInputs = with xlibs; with stdenv.lib; [ glib cairo pango gdk_pixbuf atk ] <del> ++ optionals stdenv.isLinux [ libXrandr libXrender libXcomposite libXi libXcursor ] ++ optional stdenv.isDarwin x11 </del> <ins> ++ optionals (stdenv.isLinux || stdenv.isDarwin) [ libXrandr libXrender libXcomposite libXi libXcursor ] ++ optionals stdenv.isDarwin [ x11 libXdamage ] </ins> ++ libintlOrEmpty ++ optional xineramaSupport libXinerama ++ optionals cupsSupport [ cups ]; <del> configureFlags = "--with-xinput=yes"; </del> <ins> configureFlags = if stdenv.isDarwin then "--disable-glibtest --disable-introspection --disable-visibility" else "--with-xinput=yes"; </ins> postInstall = "rm -rf $out/share/gtk-doc";


Question:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by

{ stdenv, fetchurl, pkgconfig, glib, freetype, cairo, libintlOrEmpty , icu, graphite2 , withIcu ? false # recommended by upstream as default, but most don't needed and it's big <del> , withGraphite2 ? true # it is small and major distros do include it </del> <ins> , withGraphite2 ? !stdenv.isDarwin # it is small and major distros do include it </ins> }: # TODO: split non-icu and icu lib into different outputs?


Question:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by

enableParallelBuilding = true; <del> doCheck = true; </del> <ins> # jww (2014-05-05): The tests currently fail on Darwin: # # ERROR:testiter.c:139:iter_char_test: assertion failed: (extents.width == x1 - x0) # .../bin/sh: line 5: 14823 Abort trap: 6 srcdir=. PANGO_RC_FILE=./pangorc ${dir}$tst # FAIL: testiter doCheck = !stdenv.isDarwin; </ins> postInstall = "rm -rf $out/share/gtk-doc"; meta = {


Question:
It used to be possible to build (it is possible on 20.09), but these days it fails with: I’ll try to bisect it…
Bisecting points to by Nathan, do you have a hunch?
Cargoculting what I saw in the GHC code, trying this right now:
Seems to work, fix in
There appear to be multiple linker bugs affecting at least Rust and GHC with Musl . Both bfd or gold had issues, gold seems a little worse. I would suggest trying lld, it may fix it.
lld with gcc is currently not supported and I think last time I tried we can't build OCaml and all its dependencies with clang+lld fully yet…
The second commit of ("match leading/trailing arguments") should fix this
That's great news!
Fixed by

libXmu libXext xextproto libSM libICE; ghostscript = ghostscriptX; harfbuzz = harfbuzz.override { <del> withIcu = true; withGraphite2 = true; </del> <ins> withIcu = true; withGraphite2 = !stdenv.isDarwin; </ins> }; };


Question:
, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
NixOS 20.09 is EOL, so this issue isn't actionable anymore.

buildCommand = "sed s/dot_root/agroot/g ${raw_patch} > $out"; }; # 2.42 has the patch included <del> patches = optional (lib.versionOlder version "2.42") patchToUse; </del> <ins> patches = optional (lib.versionOlder version "2.42") patchToUse ++ optionals (lib.versionOlder version "2.46.0") [ (fetchpatch { name = "CVE-2020-18032.patch"; url = "https://gitlab.com/graphviz/graphviz/-/commit/784411ca3655c80da0f6025ab20634b2a6ff696b.patch"; sha256 = "1nkw9ism8lkfvxsp5fh95i2l5s5cbjsidbb3g1kjfv10rxkyb41m"; }) ]; </ins> in stdenv.mkDerivation {


Question: , CVSSv3=7.5 (nixos-20.09, nixos-unstable) CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc

in { openvpn_24 = generic { <del> version = "2.4.9"; sha256 = "1qpbllwlha7cffsd5dlddb8rl22g9rar5zflkz1wrcllhvfkl7v4"; </del> <ins> version = "2.4.11"; sha256 = "06s4m0xvixjhd3azrzbsf4j86kah4xwr2jp6cmcpc7db33rfyyg5"; </ins> }; openvpn = generic { <del> version = "2.5.0"; sha256 = "sha256-AppCbkTWVstOEYkxnJX+b8mGQkdyT1WZ2Z35xMNHj70="; </del> <ins> version = "2.5.2"; sha256 = "sha256-sSdDg2kB82Xvr4KrJJOWfhshwh60POmo2hACoXycHcg="; </ins> }; }


Question: Describe the bug fails to build on master/release-21.05. The build failure ( is not found anymore by cmake) appeared with the update of from 2.9.10 to 2.9.12. Addressing CC

<ins> diff --color -ur a/CMakeLists.txt b/CMakeLists.txt --- a/CMakeLists.txt	2021-05-30 13:46:22.256040282 +0200 +++ b/CMakeLists.txt	2021-05-30 14:15:42.530181216 +0200 @@ -333,7 +333,7 @@ # So, try first to find the CMake module provided by libxml2 package, then fallback # on the CMake's FindLibXml2.cmake module (which can lack some definition, especially # in static build case). -find_package(LibXml2 QUIET NO_MODULE) +find_package(LibXml2 QUIET MODULE) if(DEFINED LIBXML2_VERSION_STRING) set(LIBXML2_FOUND ON) set(LIBXML2_INCLUDE_DIR ${LIBXML2_INCLUDE_DIRS}) Seulement dans b: good.patch </ins>


Question: Describe the bug fails to build on master/release-21.05. The build failure ( is not found anymore by cmake) appeared with the update of from 2.9.10 to 2.9.12. Addressing CC

sha256 = "0psw67mzysdb8fkh8xpcwicm7z94k8plkcc8ymxyvl6inshq0mc7"; }; <ins> # Revert after https://github.com/NixOS/nixpkgs/issues/125008 is # fixed properly patches = [ ./cmake-fix-libxml2-find-package.patch ]; </ins> nativeBuildInputs = [ cmake flex


Question:
Describe the bug The rhdf5 library does not work on latest release. To Reproduce Expected behavior A shell with R and rhdf5. Additional context Instead I get: Notify maintainers Metadata Maintainer information:
"6.topic: rust" should be removed, this is an R package, not Rust.
This was fixed in

Rglpk = [ pkgs.glpk ]; RGtk2 = [ pkgs.gtk2.dev ]; rhdf5 = [ pkgs.zlib ]; <del> Rhdf5lib = [ pkgs.zlib ]; </del> <ins> Rhdf5lib = [ pkgs.zlib.dev ]; </ins> Rhpc = [ pkgs.zlib pkgs.bzip2.dev pkgs.icu pkgs.xz.dev pkgs.mpi pkgs.pcre.dev ]; Rhtslib = [ pkgs.zlib.dev pkgs.automake pkgs.autoconf pkgs.bzip2.dev pkgs.xz.dev pkgs.curl.dev ]; rjags = [ pkgs.jags ];


Question:
Describe the bug The rhdf5 library does not work on latest release. To Reproduce Expected behavior A shell with R and rhdf5. Additional context Instead I get: Notify maintainers Metadata Maintainer information:
"6.topic: rust" should be removed, this is an R package, not Rust.
This was fixed in

index e2d292e..b13c0db 100755 --- a/configure +++ b/configure <del> @@ -2880,6 +2880,7 @@ $MAKE </del> <ins> @@ -3874,6 +3874,7 @@ </ins> echo "building the hdf5 library..."; cd ../; <del> ## we add the '-w' flag to suppress all the warnings hdf5 prints </del> +sed -i 's#/bin/mv#mv#' configure <del> ./configure --with-pic --enable-shared=no --enable-cxx  --with-szlib  CXX="${CXX}" CXFLAGS="${CXXFLAGS} -w"  </del> <ins> ./configure --with-pic --enable-shared=no --enable-cxx --enable-hl  --with-szlib=${SZIP_HOME} --with-zlib=${ZLIB_HOME}  ${WITH_S3_VFD}  </ins>


Question:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

config = mkIf cfg.enable { environment.systemPackages = [ pkgs.auto-cpufreq ]; <del> systemd.packages = [ pkgs.auto-cpufreq ]; systemd.services.auto-cpufreq.path = with pkgs; [ bash coreutils ]; </del> <ins> systemd = { packages = [ pkgs.auto-cpufreq ]; services.auto-cpufreq = { # Workaround for https://github.com/NixOS/nixpkgs/issues/81138 wantedBy = [ "multi-user.target" ]; path = with pkgs; [ bash coreutils ]; }; }; </ins> }; }


Question:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

python3Packages.buildPythonPackage rec { pname = "auto-cpufreq"; <del> version = "1.6.1"; </del> <ins> version = "1.6.4"; </ins> src = fetchFromGitHub { owner = "AdnanHodzic"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-oz3C1150CPfT0kkx1x7VIX/Rm06dkjyxeDPFCRJaWNc="; </del> <ins> sha256 = "sha256-9WYuAWcJGosYEsnnkqvZLXXvqF+1nBEozh6F84Kit6w="; </ins> }; propagatedBuildInputs = with python3Packages; [ click distro psutil ];


Question:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

diff --git a/auto_cpufreq/core.py b/auto_cpufreq/core.py <del> index a685db8..1ca1ca1 100644 </del> <ins> index 83d0d64..04b5035 100644 </ins> --- a/auto_cpufreq/core.py +++ b/auto_cpufreq/core.py <del> @@ -72,7 +72,7 @@ def app_version(): print("Git commit:", check_output(["git", "describe", "--always"]).strip().decode()) else: print(getoutput("pacman -Qi auto-cpufreq | grep Version")) -    else: +    else: # source code (auto-cpufreq-installer) try: print("Git commit:", check_output(["git", "describe", "--always"]).strip().decode()) @@ -179,31 +179,13 @@ def get_current_gov(): return print("Currently using:", getoutput("cpufreqctl.auto-cpufreq --governor").strip().split(" ")[0], "governor") </del> <ins> @@ -204,35 +204,13 @@ def get_current_gov(): </ins> def cpufreqctl(): -    """


Question:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

-    """ - -    # detect if running on a SNAP <del> -    if os.getenv('PKG_MARKER') == "SNAP": </del> <ins> -    if os.getenv("PKG_MARKER") == "SNAP": </ins> -        pass -    else: -        # deploy cpufreqctl.auto-cpufreq script -        if os.path.isfile("/usr/bin/cpufreqctl"): <del> -            shutil.copy(SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq") </del> <ins> -            shutil.copy( -                SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq" -            ) </ins> -        else: <del> -            shutil.copy(SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq") </del> <ins> -            shutil.copy( -                SCRIPTS_DIR / "cpufreqctl.sh", "/usr/bin/cpufreqctl.auto-cpufreq" -            ) </ins> +    # scripts are already in the correct place +    pass


Question:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

-    remove cpufreqctl.auto-cpufreq script -    """ -    # detect if running on a SNAP <del> -    if os.getenv('PKG_MARKER') == "SNAP": </del> <ins> -    if os.getenv("PKG_MARKER") == "SNAP": </ins> -        pass -    else: -        if os.path.isfile("/usr/bin/cpufreqctl.auto-cpufreq"):


Question:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

+    # no need to restore +    pass def footer(l=79): <del> print("n" + "-" * l + "n") @@ -233,74 +215,12 @@ def remove_complete_msg(): footer() </del> <ins> @@ -276,76 +254,13 @@ def remove_complete_msg(): </ins> def deploy_daemon(): -    print("n" + "-" * 21 + " Deploying auto-cpufreq as a daemon " + "-" * 22 + "n")


Question:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

-            f.seek(0) -            f.truncate() -            f.write(content.replace(orig_set, change_set)) <del> -    except: -        print("nERROR:nWas unable to turn off bluetooth on boot") </del> <ins> -    except Exception as e: -        print(f"nERROR:nWas unable to turn off bluetooth on bootn{repr(e)}") </ins> - -    auto_cpufreq_stats_path.touch(exist_ok=True) - -    print("n* Deploy auto-cpufreq install script") <del> -    shutil.copy(SCRIPTS_DIR / "auto-cpufreq-install.sh", "/usr/bin/auto-cpufreq-install") </del> <ins> -    shutil.copy( -        SCRIPTS_DIR / "auto-cpufreq-install.sh", "/usr/bin/auto-cpufreq-install" -    ) </ins> - -    print("n* Deploy auto-cpufreq remove script") -    shutil.copy(SCRIPTS_DIR / "auto-cpufreq-remove.sh", "/usr/bin/auto-cpufreq-remove") - -    call("/usr/bin/auto-cpufreq-install", shell=True) <del> - </del> +    # prevent needless copying and system changes +    pass # remove auto-cpufreq daemon def remove(): -


Question:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

-            f.seek(0) -            f.truncate() -            f.write(content.replace(change_set, orig_set)) <del> -    except: -        print("nERROR:nWas unable to turn on bluetooth on boot") </del> <ins> -    except Exception as e: -        print(f"nERROR:nWas unable to turn on bluetooth on bootn{repr(e)}") </ins> - -    # run auto-cpufreq daemon install script -    call("/usr/bin/auto-cpufreq-remove", shell=True)


Question:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it

def gov_check(): for gov in get_avail_gov(): <del> @@ -331,7 +251,7 @@ def countdown(s): if auto_cpufreq_stats_file is not None: auto_cpufreq_stats_file.seek(0) auto_cpufreq_stats_file.truncate(0) - + # execution timestamp from datetime import datetime now = datetime.now() </del> diff --git a/scripts/cpufreqctl.sh b/scripts/cpufreqctl.sh index 63a2b5b..e157efe 100755 --- a/scripts/cpufreqctl.sh


Question:
As reported on we need some patches: In particular: gnome-settings-daemon needs bluetoothd needs cc
At least for g-s-d we're already on 40.0.1, which seems to have the fix? Both commits referenced (!232, !234) are there, but maybe I'm misreading. Not sure if we want to address bluetoothd with , but regardless I have a commit ready.
Above is no longer necessary with 5.60. I'll open a bump for that instead.

]; in stdenv.mkDerivation rec { pname = "bluez"; <del> version = "5.59"; </del> <ins> version = "5.60"; </ins> src = fetchurl { url = "mirror://kernel/linux/bluetooth/${pname}-${version}.tar.xz"; <del> sha256 = "05kk8zdh3msf5j88jbai8m877rvya6fpkzhicfhv5gyhhsrrasq4"; </del> <ins> sha256 = "sha256-cQmZWA0B7lnsWF5efAf9lO3e3AAaom/nRkxUb52UUwQ="; </ins> }; buildInputs = [


Question: Describe the bug The current downloads 2 patches, both of them 404. I realized this when I tried to build my system from scratch without substitors. To Reproduce a system that somehow depends on mercurial (not exactly sure if this is reproducible with just or similar, this was also on a content addressed machine, and reproducing the issue in a more isolated way would require another toolchain bootstrap which takes several days) the system from scratch using see errors like this: Expected behavior mercurial builds without errors Screenshots See log output from reproduction. Also ing the URLs as in the derivation linked in the description result in 404. Additional context The exact commit the system was build from is nixos/nixpkgs/, though as the same path URLs are used in nixos/nixpkgs/master, this is probably only partially relevant. Notify maintainers cc Metadata nix shell nixpkgs#nix-info --option trusted-substituters -c nix-info -m system: host os: multi-user?: sandbox: version: channels(nmelzer): nixpkgs: Maintainer information:

patches = [ # https://phab.mercurial-scm.org/D10638, needed for below patch to apply (fetchpatch { <del> url = "https://phab.mercurial-scm.org/file/data/oymk4awh2dd7q6cwjbzu/PHID-FILE-bfcr7qrp5spg42wspxpd/D10638.diff"; </del> <ins> url = "https://phab.mercurial-scm.org/file/data/l7p2r4zcctcr3pzlybv2/PHID-FILE-bwjzxlz6sbegk3s4irik/D10638.diff"; </ins> sha256 = "0mfi324is02l7cnd3j0gbmg5rpyyqn3afg3f73flnfwmz5njqa5f"; }) # https://phab.mercurial-scm.org/D10639, fixes https://bz.mercurial-scm.org/show_bug.cgi?id=6514 (fetchpatch { <del> url = "https://phab.mercurial-scm.org/file/data/re4uqdhtknjiacx2ogwu/PHID-FILE-4m26id65dno5gzix2ngh/D10639.diff"; </del> <ins> url = "https://phab.mercurial-scm.org/file/data/v53nhburhtkhpccyecei/PHID-FILE-6v34oll6r2gkqo4ng5nt/D10639.diff"; </ins> sha256 = "0h5ilrd2x1789fr6sf4k1mcvxdh0xdyr94yawdacw87v3x12c8cb"; }) ];


Question:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

# Enable libfabric support (necessary for Omnipath networks) on x86_64 linux , fabricSupport ? stdenv.isLinux && stdenv.isx86_64 <ins> # Enable Fortran support , fortranSupport ? !(stdenv.isDarwin && stdenv.isAarch64) </ins> }: assert !cudaSupport || cudatoolkit != null; let <del> version = "4.1.1"; </del> cudatoolkit_joined = symlinkJoin { name = "${cudatoolkit.name}-unsplit"; paths = [ cudatoolkit.out cudatoolkit.lib ]; }; in stdenv.mkDerivation rec { pname = "openmpi"; <del> inherit version; </del> <ins> version = "4.1.1"; </ins> src = with lib.versions; fetchurl { url = "https://www.open-mpi.org/software/ompi/v${major version}.${minor version}/downloads/${pname}-${version}.tar.bz2";


Question:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

find -name "Makefile.in" -exec sed -i "s/`date`/$ts/" {} ; ''; <del> buildInputs = with stdenv; [ gfortran zlib ] ++ lib.optionals isLinux [ libnl numactl pmix ucx ] </del> <ins> buildInputs = [ zlib ] ++ lib.optionals fortranSupport [ gfortran ] ++ lib.optionals stdenv.isLinux [ libnl numactl pmix ucx ] </ins> ++ lib.optionals cudaSupport [ cudatoolkit ] ++ [ libevent hwloc ] <del> ++ lib.optional (isLinux || isFreeBSD) rdma-core </del> <ins> ++ lib.optional (stdenv.isLinux || stdenv.isFreeBSD) rdma-core </ins> ++ lib.optional fabricSupport [ libpsm2 libfabric ]; nativeBuildInputs = [ perl ]; <del> configureFlags = with stdenv; lib.optional (!cudaSupport) "--disable-mca-dso" ++ lib.optionals isLinux  [ </del> <ins> configureFlags = lib.optional (!cudaSupport) "--disable-mca-dso" ++ lib.optional (!fortranSupport) "--disable-mpi-fortran" ++ lib.optionals stdenv.isLinux  [ </ins> "--with-libnl=${libnl.dev}" "--with-pmix=${pmix}" "--with-pmix-libdir=${pmix}/lib"


Question:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

sed -i 's:compiler=.*:compiler=${targetPackages.stdenv.cc}/bin/${targetPackages.stdenv.cc.targetPrefix}c++:'  $out/share/openmpi/mpic++-wrapper-data.txt <ins> '' + lib.optionalString fortranSupport '' </ins> sed -i 's:compiler=.*:compiler=${gfortran}/bin/${gfortran.targetPrefix}gfortran:'   $out/share/openmpi/mpifort-wrapper-data.txt


Question:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

# fails to configure on darwin due to gmp not found configureFlags = [ "LIBS=-L${gmp}/lib" "CXXFLAGS=-I${gmp.dev}/include" ]; <del> # disable stackprotector on aarch64-darwin for now # https://github.com/NixOS/nixpkgs/issues/127608 hardeningDisable = lib.optionals (stdenv.isAarch64 && stdenv.isDarwin) [ "stackprotector" ]; </del> postPatch = '' sed -e "s@ /bin/bash@bash@g" -i Makefile.std find . -exec sed -e "s@/usr/bin/perl@${perl}/bin/perl@g" -i '{}' ';'


Question:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

install_name_tool -change libblas.dylib ${blas}/lib/libblas.dylib $out/lib/libarpack.dylib ''; <del> # disable stackprotector on aarch64-darwin for now # https://github.com/NixOS/nixpkgs/issues/127608 hardeningDisable = lib.optionals (stdenv.isAarch64 && stdenv.isDarwin) [ "stackprotector" ]; </del> meta = { homepage = "https://github.com/opencollab/arpack-ng"; description = ''


Question:
Describe the bug I'm on a mission to get (and thence ) compiling on M1 Macs, and having fixed , the next stumbling block is 4.1.1. Sadly, the build fails with , presumably related to . To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. Screenshots Additional context This works fine when built for x8664 on the same machine. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(steve): nixpkgs: Maintainer information:
Submitted PR which disables Fortran support for OpenMPI on aarch64-darwin. Would that fix the issue for you or do you require Fortran?
This seems to be the build failure:
I actually have no idea if I require Fortran. I mean, presumably it's enabled for some reason, so I'm a little wary of disabling it on only one platform/arch combination: that feels like an atypical workaround.
To reproduce: I wonder if the gcc maintainers can offer any insight?
seems to hint at the stack-protector hardening, so perhaps something like could work around that? (no idea what's the real cause though, and I have no Darwin machine at hand)
You were right! Sent a PR in

)] ; <del> # disable stackprotector on aarch64-darwin for now # https://github.com/NixOS/nixpkgs/issues/127608 # # build error: # # /private/tmp/nix-build-sundials-6.3.0.drv-0/ccD2dUtR.s:21:15: error: index must be an integer in range [-256, 255]. #         ldr     x0, [x0, ___stack_chk_guard];momd #                          ^ # /private/tmp/nix-build-sundials-6.3.0.drv-0/ccD2dUtR.s:46:15: error: index must be an integer in range [-256, 255]. #         ldr     x0, [x0, ___stack_chk_guard];momd # # See also a proposed solution: https://github.com/NixOS/nixpkgs/pull/151983 hardeningDisable = lib.optionals (stdenv.isAarch64 && stdenv.isDarwin) [ "stackprotector" ]; </del> doCheck = true; checkTarget = "test";


Question: This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

<ins> # Adding Custom Packages {#sec-custom-packages} It's possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the [Nixpkgs manual](https://nixos.org/nixpkgs/manual). In short, you clone Nixpkgs: ```ShellSession $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs ``` Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to [](#opt-environment.systemPackages), e.g. ```nix environment.systemPackages = [ pkgs.my-package ]; ``` and you run `nixos-rebuild`, specifying your own Nixpkgs tree: ```ShellSession # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs ``` The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the [GNU Hello](https://www.gnu.org/software/hello/) package directly in `configuration.nix`: ```nix environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; }; in [ my-hello ]; ``` Of course, you can also move the definition of `my-hello` into a separate Nix expression, e.g. ```nix environment.systemPackages = [ (import ./my-hello.nix) ]; ``` where `my-hello.nix` contains: ```nix with import <nixpkgs> {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; } ``` This allows testing the package easily: ```ShellSession $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! ``` </ins>


Question: This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

<del> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" version="5.0" xml:id="sec-custom-packages"> <title>Adding Custom Packages</title> <para> It’s possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the <link xlink:href="https://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, you clone Nixpkgs: <screen> <prompt>$ </prompt>git clone https://github.com/NixOS/nixpkgs <prompt>$ </prompt>cd nixpkgs </screen> Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to <literal>environment.systemPackages</literal>, e.g. <programlisting> <xref linkend="opt-environment.systemPackages"/> = [ pkgs.my-package ]; </programlisting> and you run <command>nixos-rebuild</command>, specifying your own Nixpkgs tree: <screen> <prompt># </prompt>nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs</screen> </para> <para> The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link> package directly in <filename>configuration.nix</filename>: <programlisting> <xref linkend="opt-environment.systemPackages"/> = let my-hello = with pkgs; stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; }; in [ my-hello ]; </programlisting> Of course, you can also move the definition of <literal>my-hello</literal> into a separate Nix expression, e.g. <programlisting> <xref linkend="opt-environment.systemPackages"/> = [ (import ./my-hello.nix) ]; </programlisting> where <filename>my-hello.nix</filename> contains: <programlisting> with import <nixpkgs> {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; } </programlisting> This allows testing the package easily: <screen> <prompt>$ </prompt>nix-build my-hello.nix <prompt>$ </prompt>./result/bin/hello Hello, world! </screen> </para> </section> </del>


Question: This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

<ins> # Customising Packages {#sec-customising-packages} Some packages in Nixpkgs have options to enable or disable optional functionality or change other aspects of the package. For instance, the Firefox wrapper package (which provides Firefox with a set of plugins such as the Adobe Flash player) has an option to enable the Google Talk plugin. It can be set in `configuration.nix` as follows: `nixpkgs.config.firefox.enableGoogleTalkPlugin = true;` ::: {.warning} Unfortunately, Nixpkgs currently lacks a way to query available configuration options. ::: Apart from high-level options, it's possible to tweak a package in almost arbitrary ways, such as changing or disabling dependencies of a package. For instance, the Emacs package in Nixpkgs by default has a dependency on GTK 2. If you want to build it against GTK 3, you can specify that as follows: ```nix environment.systemPackages = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ]; ``` The function `override` performs the call to the Nix function that produces Emacs, with the original arguments amended by the set of arguments specified by you. So here the function argument `gtk` gets the value `pkgs.gtk3`, causing Emacs to depend on GTK 3. (The parentheses are necessary because in Nix, function application binds more weakly than list construction, so without them, [](#opt-environment.systemPackages) would be a list with two elements.) Even greater customisation is possible using the function `overrideAttrs`. While the `override` mechanism above overrides the arguments of a package function, `overrideAttrs` allows changing the *attributes* passed to `mkDerivation`. This permits changing any aspect of the package, such as the source code. For instance, if you want to override the source code of Emacs, you can say: ```nix environment.systemPackages = [ (pkgs.emacs.overrideAttrs (oldAttrs: { name = "emacs-25.0-pre"; src = /path/to/my/emacs/tree; })) ]; ``` Here, `overrideAttrs` takes the Nix derivation specified by `pkgs.emacs` and produces a new derivation in which the original's `name` and `src` attribute have been replaced by the given values by re-calling `stdenv.mkDerivation`. The original attributes are accessible via the function argument, which is conventionally named `oldAttrs`. The overrides shown above are not global. They do not affect the original package; other packages in Nixpkgs continue to depend on the original rather than the customised package. This means that if another package in your system depends on the original package, you end up with two instances of the package. If you want to have everything depend on your customised instance, you can apply a *global* override as follows: ```nix nixpkgs.config.packageOverrides = pkgs: { emacs = pkgs.emacs.override { gtk = pkgs.gtk3; }; }; ``` The effect of this definition is essentially equivalent to modifying the `emacs` attribute in the Nixpkgs source tree. Any package in Nixpkgs that depends on `emacs` will be passed your customised instance. (However, the value `pkgs.emacs` in `nixpkgs.config.packageOverrides` refers to the original rather than overridden instance, to prevent an infinite recursion.) </ins>


Question: This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

<del> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xi="http://www.w3.org/2001/XInclude" version="5.0" xml:id="sec-customising-packages"> <title>Customising Packages</title> <para> Some packages in Nixpkgs have options to enable or disable optional functionality or change other aspects of the package. For instance, the Firefox wrapper package (which provides Firefox with a set of plugins such as the Adobe Flash player) has an option to enable the Google Talk plugin. It can be set in <filename>configuration.nix</filename> as follows: <filename> nixpkgs.config.firefox.enableGoogleTalkPlugin = true; </filename> </para> <warning> <para> Unfortunately, Nixpkgs currently lacks a way to query available configuration options. </para> </warning> <para> Apart from high-level options, it’s possible to tweak a package in almost arbitrary ways, such as changing or disabling dependencies of a package. For instance, the Emacs package in Nixpkgs by default has a dependency on GTK 2. If you want to build it against GTK 3, you can specify that as follows: <programlisting> <xref linkend="opt-environment.systemPackages"/> = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ]; </programlisting> The function <varname>override</varname> performs the call to the Nix function that produces Emacs, with the original arguments amended by the set of arguments specified by you. So here the function argument <varname>gtk</varname> gets the value <literal>pkgs.gtk3</literal>, causing Emacs to depend on GTK 3. (The parentheses are necessary because in Nix, function application binds more weakly than list construction, so without them, <xref linkend="opt-environment.systemPackages"/> would be a list with two elements.) </para> <para> Even greater customisation is possible using the function <varname>overrideAttrs</varname>. While the <varname>override</varname> mechanism above overrides the arguments of a package function, <varname>overrideAttrs</varname> allows changing the <emphasis>attributes</emphasis> passed to <literal>mkDerivation</literal>. This permits changing any aspect of the package, such as the source code. For instance, if you want to override the source code of Emacs, you can say: <programlisting> <xref linkend="opt-environment.systemPackages"/> = [ (pkgs.emacs.overrideAttrs (oldAttrs: { name = "emacs-25.0-pre"; src = /path/to/my/emacs/tree; })) ]; </programlisting> Here, <varname>overrideAttrs</varname> takes the Nix derivation specified by <varname>pkgs.emacs</varname> and produces a new derivation in which the original’s <literal>name</literal> and <literal>src</literal> attribute have been replaced by the given values by re-calling <literal>stdenv.mkDerivation</literal>. The original attributes are accessible via the function argument, which is conventionally named <varname>oldAttrs</varname>. </para> <para> The overrides shown above are not global. They do not affect the original package; other packages in Nixpkgs continue to depend on the original rather than the customised package. This means that if another package in your system depends on the original package, you end up with two instances of the package. If you want to have everything depend on your customised instance, you can apply a <emphasis>global</emphasis> override as follows: <screen> nixpkgs.config.packageOverrides = pkgs: { emacs = pkgs.emacs.override { gtk = pkgs.gtk3; }; }; </screen> The effect of this definition is essentially equivalent to modifying the <literal>emacs</literal> attribute in the Nixpkgs source tree. Any package in Nixpkgs that depends on <literal>emacs</literal> will be passed your customised instance. (However, the value <literal>pkgs.emacs</literal> in <varname>nixpkgs.config.packageOverrides</varname> refers to the original rather than overridden instance, to prevent an infinite recursion.) </para> </section> </del>


Question: This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

<command>nixos-rebuild switch</command>. </para> <del> <xi:include href="customizing-packages.xml" /> </del> <ins> <xi:include href="../from_md/configuration/customizing-packages.section.xml" /> </ins> <del> <xi:include href="adding-custom-packages.xml" /> </del> <ins> <xi:include href="../from_md/configuration/adding-custom-packages.section.xml" /> </ins> </section>


Question: This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

<ins> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-custom-packages"> <title>Adding Custom Packages</title> <para> It’s possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the <link xlink:href="https://nixos.org/nixpkgs/manual">Nixpkgs manual</link>. In short, you clone Nixpkgs: </para> <programlisting> $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs </programlisting> <para> Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to <xref linkend="opt-environment.systemPackages" />, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ pkgs.my-package ]; </programlisting> <para> and you run <literal>nixos-rebuild</literal>, specifying your own Nixpkgs tree: </para> <programlisting> # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs </programlisting> <para> The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the <link xlink:href="https://www.gnu.org/software/hello/">GNU Hello</link> package directly in <literal>configuration.nix</literal>: </para> <programlisting language="bash"> environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; }; in [ my-hello ]; </programlisting> <para> Of course, you can also move the definition of <literal>my-hello</literal> into a separate Nix expression, e.g. </para> <programlisting language="bash"> environment.systemPackages = [ (import ./my-hello.nix) ]; </programlisting> <para> where <literal>my-hello.nix</literal> contains: </para> <programlisting language="bash"> with import <nixpkgs> {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; } </programlisting> <para> This allows testing the package easily: </para> <programlisting> $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! </programlisting> </section> </ins>


Question: This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.

<ins> <section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-customising-packages"> <title>Customising Packages</title> <para> Some packages in Nixpkgs have options to enable or disable optional functionality or change other aspects of the package. For instance, the Firefox wrapper package (which provides Firefox with a set of plugins such as the Adobe Flash player) has an option to enable the Google Talk plugin. It can be set in <literal>configuration.nix</literal> as follows: <literal>nixpkgs.config.firefox.enableGoogleTalkPlugin = true;</literal> </para> <warning> <para> Unfortunately, Nixpkgs currently lacks a way to query available configuration options. </para> </warning> <para> Apart from high-level options, it’s possible to tweak a package in almost arbitrary ways, such as changing or disabling dependencies of a package. For instance, the Emacs package in Nixpkgs by default has a dependency on GTK 2. If you want to build it against GTK 3, you can specify that as follows: </para> <programlisting language="bash"> environment.systemPackages = [ (pkgs.emacs.override { gtk = pkgs.gtk3; }) ]; </programlisting> <para> The function <literal>override</literal> performs the call to the Nix function that produces Emacs, with the original arguments amended by the set of arguments specified by you. So here the function argument <literal>gtk</literal> gets the value <literal>pkgs.gtk3</literal>, causing Emacs to depend on GTK 3. (The parentheses are necessary because in Nix, function application binds more weakly than list construction, so without them, <xref linkend="opt-environment.systemPackages" /> would be a list with two elements.) </para> <para> Even greater customisation is possible using the function <literal>overrideAttrs</literal>. While the <literal>override</literal> mechanism above overrides the arguments of a package function, <literal>overrideAttrs</literal> allows changing the <emphasis>attributes</emphasis> passed to <literal>mkDerivation</literal>. This permits changing any aspect of the package, such as the source code. For instance, if you want to override the source code of Emacs, you can say: </para> <programlisting language="bash"> environment.systemPackages = [ (pkgs.emacs.overrideAttrs (oldAttrs: { name = "emacs-25.0-pre"; src = /path/to/my/emacs/tree; })) ]; </programlisting> <para> Here, <literal>overrideAttrs</literal> takes the Nix derivation specified by <literal>pkgs.emacs</literal> and produces a new derivation in which the original’s <literal>name</literal> and <literal>src</literal> attribute have been replaced by the given values by re-calling <literal>stdenv.mkDerivation</literal>. The original attributes are accessible via the function argument, which is conventionally named <literal>oldAttrs</literal>. </para> <para> The overrides shown above are not global. They do not affect the original package; other packages in Nixpkgs continue to depend on the original rather than the customised package. This means that if another package in your system depends on the original package, you end up with two instances of the package. If you want to have everything depend on your customised instance, you can apply a <emphasis>global</emphasis> override as follows: </para> <programlisting language="bash"> nixpkgs.config.packageOverrides = pkgs: { emacs = pkgs.emacs.override { gtk = pkgs.gtk3; }; }; </programlisting> <para> The effect of this definition is essentially equivalent to modifying the <literal>emacs</literal> attribute in the Nixpkgs source tree. Any package in Nixpkgs that depends on <literal>emacs</literal> will be passed your customised instance. (However, the value <literal>pkgs.emacs</literal> in <literal>nixpkgs.config.packageOverrides</literal> refers to the original rather than overridden instance, to prevent an infinite recursion.) </para> </section> </ins>