Question:
Carry over discussion from IRC #nixos-dev and . Inspired by the doc change in recommending top-level usage of over , we want to reduce confusion for newcomers and unnecessary complexity by making the canonical way to access the Nix library. We may still want to keep to not break external code, and place a or similar at its definition site. There are over files where occurs at least once. Beyond splitting this change across multiple PRs, in what ways can the change be automated? Pinging
In the short term, we could add this check in ofbrorg and , and update any examples in the documentation to reduce new usage of .
Don't forget things like and .
Ah. So 45K occurrences across 11.8K files.
toplevel is done
the xorg dep generator also doesn’t put it in its output anymore
trewide rewrite in
doc changes in
Graph of occurrences over time:
Nice! What scripts did you use to generate it?
There's a source code link now :)
Found another large source of s. Fixing cabal2nix should remove around 24k occurrences in .
Status report
Just found out that counts stuff like as well, so
Is it ok to rewrite to ?
That's the lib output of , so no.
an easy way to find out is to evaluate both in
Subfolders of with <10 changes needed in PR
Around + replacements out of 30k+ are concentrated in - should be trivial to regenerate the file with the new desired contents.
I'm working on it but it's a bit more complicated than I anticipated.
What problems are you running into?
Part of code generation of cabal2nix is in an external dependency, so I had to open two PRs. The dependency is itself on Hackage, so we may have to wait until the change propagates to Stackage LTS and then Nixpkgs, unless peti will use an override or something: I'm not familiar with the cabal2nix workflow.
I think the haskell-updates are mostly done from a local checkout of cabal2nix, so it depends mostly on what version peter is using. You can also probably just ask him, he is generally available for such things on his .
could you help here?
The Haskell infrastructure has switched to the new style with commit . It will land in this Friday. I have also updated the generator code and released new versions to Hackage, so I guess the Haskell infrastructure can be considered done.
Thank you
More accurate regex: (the one above captures stuff like
When is merged, this will be the result Three Nix files remain that use directly.
The last usages of it can be found by commenting out where it is inherited in .
I just got this warning while doing a , but it doesn't give me any info as to which derivations are at fault. Is there any way we could improve the message to identify culprits?
With , you should get a hard error which will allow you to use . Or you can update Nixpkgs, since it has been removed in

<del> { stdenv </del> <ins> { lib , stdenv </ins> , autoPatchelfHook , fetchurl , file


Question:
Carry over discussion from IRC #nixos-dev and . Inspired by the doc change in recommending top-level usage of over , we want to reduce confusion for newcomers and unnecessary complexity by making the canonical way to access the Nix library. We may still want to keep to not break external code, and place a or similar at its definition site. There are over files where occurs at least once. Beyond splitting this change across multiple PRs, in what ways can the change be automated? Pinging
In the short term, we could add this check in ofbrorg and , and update any examples in the documentation to reduce new usage of .
Don't forget things like and .
Ah. So 45K occurrences across 11.8K files.
toplevel is done
the xorg dep generator also doesn’t put it in its output anymore
trewide rewrite in
doc changes in
Graph of occurrences over time:
Nice! What scripts did you use to generate it?
There's a source code link now :)
Found another large source of s. Fixing cabal2nix should remove around 24k occurrences in .
Status report
Just found out that counts stuff like as well, so
Is it ok to rewrite to ?
That's the lib output of , so no.
an easy way to find out is to evaluate both in
Subfolders of with <10 changes needed in PR
Around + replacements out of 30k+ are concentrated in - should be trivial to regenerate the file with the new desired contents.
I'm working on it but it's a bit more complicated than I anticipated.
What problems are you running into?
Part of code generation of cabal2nix is in an external dependency, so I had to open two PRs. The dependency is itself on Hackage, so we may have to wait until the change propagates to Stackage LTS and then Nixpkgs, unless peti will use an override or something: I'm not familiar with the cabal2nix workflow.
I think the haskell-updates are mostly done from a local checkout of cabal2nix, so it depends mostly on what version peter is using. You can also probably just ask him, he is generally available for such things on his .
could you help here?
The Haskell infrastructure has switched to the new style with commit . It will land in this Friday. I have also updated the generator code and released new versions to Hackage, so I guess the Haskell infrastructure can be considered done.
Thank you
More accurate regex: (the one above captures stuff like
When is merged, this will be the result Three Nix files remain that use directly.
The last usages of it can be found by commenting out where it is inherited in .
I just got this warning while doing a , but it doesn't give me any info as to which derivations are at fault. Is there any way we could improve the message to identify culprits?
With , you should get a hard error which will allow you to use . Or you can update Nixpkgs, since it has been removed in

pleroma = nixosTests.pleroma; }; <del> meta = { </del> <ins> meta = with lib; { </ins> description = "ActivityPub microblogging server"; homepage = https://git.pleroma.social/pleroma/pleroma; <del> license = stdenv.lib.licenses.agpl3; maintainers = with stdenv.lib.maintainers; [ ninjatrappeur ]; </del> <ins> license = licenses.agpl3; maintainers = with maintainers; [ ninjatrappeur ]; </ins> platforms = [ "x86_64-linux" "aarch64-linux" ]; }; }


Question:
Carry over discussion from IRC #nixos-dev and . Inspired by the doc change in recommending top-level usage of over , we want to reduce confusion for newcomers and unnecessary complexity by making the canonical way to access the Nix library. We may still want to keep to not break external code, and place a or similar at its definition site. There are over files where occurs at least once. Beyond splitting this change across multiple PRs, in what ways can the change be automated? Pinging
In the short term, we could add this check in ofbrorg and , and update any examples in the documentation to reduce new usage of .
Don't forget things like and .
Ah. So 45K occurrences across 11.8K files.
toplevel is done
the xorg dep generator also doesn’t put it in its output anymore
trewide rewrite in
doc changes in
Graph of occurrences over time:
Nice! What scripts did you use to generate it?
There's a source code link now :)
Found another large source of s. Fixing cabal2nix should remove around 24k occurrences in .
Status report
Just found out that counts stuff like as well, so
Is it ok to rewrite to ?
That's the lib output of , so no.
an easy way to find out is to evaluate both in
Subfolders of with <10 changes needed in PR
Around + replacements out of 30k+ are concentrated in - should be trivial to regenerate the file with the new desired contents.
I'm working on it but it's a bit more complicated than I anticipated.
What problems are you running into?
Part of code generation of cabal2nix is in an external dependency, so I had to open two PRs. The dependency is itself on Hackage, so we may have to wait until the change propagates to Stackage LTS and then Nixpkgs, unless peti will use an override or something: I'm not familiar with the cabal2nix workflow.
I think the haskell-updates are mostly done from a local checkout of cabal2nix, so it depends mostly on what version peter is using. You can also probably just ask him, he is generally available for such things on his .
could you help here?
The Haskell infrastructure has switched to the new style with commit . It will land in this Friday. I have also updated the generator code and released new versions to Hackage, so I guess the Haskell infrastructure can be considered done.
Thank you
More accurate regex: (the one above captures stuff like
When is merged, this will be the result Three Nix files remain that use directly.
The last usages of it can be found by commenting out where it is inherited in .
I just got this warning while doing a , but it doesn't give me any info as to which derivations are at fault. Is there any way we could improve the message to identify culprits?
With , you should get a hard error which will allow you to use . Or you can update Nixpkgs, since it has been removed in

inherit lib config stdenv; }) mkDerivation; <del> # For convenience, bring in the library functions in lib/ so # packages don't have to do that themselves. inherit lib; </del> <ins> # Slated for deprecation in 21.11 lib = builtins.trace ( "Warning: `stdenv.lib` is deprecated and will be removed in the next release." + " Please use `pkgs.lib` instead." + " For more information see https://github.com/NixOS/nixpkgs/issues/108938") lib; </ins> inherit fetchurlBoot;


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

<del> { lib, stdenv, fetchurl, makeWrapper, jre , version ? "1.6" }: let versionMap = { "1.5" = { flinkVersion = "1.5.5"; sha256 = "18wqcqi3gyqd40nspih99gq7ylfs20b35f4dcrspffagwkfp2l4z"; }; "1.6" = { flinkVersion = "1.11.1"; sha256 = "0338bg2sb427c1rrf2cmsz63sz0yk6gclpli2lskq0mpx72wxpl0"; }; }; in with versionMap.${version}; </del> <ins> { lib, stdenv, fetchurl, makeWrapper, jre }: </ins> stdenv.mkDerivation rec { <del> name = "flink-${flinkVersion}"; </del> <ins> pname = "flink"; version = "1.12.1"; </ins> src = fetchurl { <del> url = "mirror://apache/flink/${name}/${name}-bin-scala_2.11.tgz"; inherit sha256; </del> <ins> url = "mirror://apache/flink/${pname}-${version}/${pname}-${version}-bin-scala_2.11.tgz"; sha256 = "146azc5wg1xby3nqz8mha959qy99z2h8032rfgs2mcl3d5rrsm2l"; </ins> }; nativeBuildInputs = [ makeWrapper ];


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

firestr = throw "firestr has been removed."; # added 2019-12-08 fish-foreign-env = throw "fish-foreign-env has been replaced with fishPlugins.foreign-env"; # added 2020-12-29, modified 2021-01-10 flameGraph = flamegraph; # added 2018-04-25 <ins> flink_1_5 = throw "flink_1_5 was removed, use flink instead"; # added 2021-01-25 </ins> flvtool2 = throw "flvtool2 has been removed."; # added 2020-11-03 foldingathome = fahclient; # added 2020-09-03 font-awesome-ttf = font-awesome; # 2018-02-25


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

fldigi = callPackage ../applications/radio/fldigi { }; flink = callPackage ../applications/networking/cluster/flink { }; <del> flink_1_5 = flink.override { version = "1.5"; }; </del> fllog = callPackage ../applications/radio/fllog { };


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

stdenv.mkDerivation rec { pname = "p11-kit"; <del> version = "0.23.21"; </del> <ins> version = "0.23.22"; </ins> src = fetchFromGitHub { owner = "p11-glue"; repo = pname; rev = version; <del> sha256 = "1w24brn8j3vwfp07p2hldw2ci06pk1cx1dvjk8jjxkccp20fk958"; </del> <ins> sha256 = "sha256-erWqElJr0iESNUk9EZiJRmSMYhns8GxuFLNw7mIIIWs="; </ins> }; outputs = [ "out" "dev"];


Question: , CVSSv3=5.3 (nixos-20.09) CVSSv3=5.3 (nixos-20.09) Scanned versions: nixos-20.09: . Cc Cc Cc Cc

buildGoPackage rec { pname = "vault"; <del> version = "1.6.0"; </del> <ins> version = "1.6.1"; </ins> src = fetchFromGitHub { owner = "hashicorp"; repo = "vault"; rev = "v${version}"; <del> sha256 = "13fasdiijxy87m33wfyd8gylyz556i0bdd7xp706ip2fcckrmz7a"; </del> <ins> sha256 = "1pgyyl2zgnr3wy4k8c5xsk2s5dpl97xdfq67lpfss7fz1bij8x47"; </ins> }; goPackagePath = "github.com/hashicorp/vault";


Question: , CVSSv3=5.3 (nixos-20.09) CVSSv3=5.3 (nixos-20.09) Scanned versions: nixos-20.09: . Cc Cc Cc Cc

{ stdenv, fetchurl, unzip }: let <del> version = "1.6.0"; </del> <ins> version = "1.6.1"; </ins> sources = let base = "https://releases.hashicorp.com/vault/${version}"; in { x86_64-linux = fetchurl { url = "${base}/vault_${version}_linux_amd64.zip"; <del> sha256 = "0fay6bw31x9kxmc52sh5qp63nfkwji74fbnlx8pj3smz3qnqw143"; </del> <ins> sha256 = "1la2pylcj9y5gr7hr4aaa49427y3lgxi2phhl46pqmr7an62pkbm"; </ins> }; i686-linux = fetchurl { url = "${base}/vault_${version}_linux_386.zip"; <del> sha256 = "0bjks9lpgl39cq55c9cyc0glhmyxzs37a2an8ynzza94gv5mgcxa"; </del> <ins> sha256 = "1a2rhv5bpv43qp74a49msrwr7djzy86irsn73jl0xnkh0k6ijci1"; </ins> }; x86_64-darwin = fetchurl { url = "${base}/vault_${version}_darwin_amd64.zip"; <del> sha256 = "0hl1k35x78y0hi3y5xjnzby1ygisqjyvdak7s61m9f363nsr1shh"; </del> <ins> sha256 = "0snswwai2ya26crm3ksifrmbdnajr36v4vamh7g65plg6vzban9a"; </ins> }; aarch64-linux = fetchurl { url = "${base}/vault_${version}_linux_arm64.zip"; <del> sha256 = "018a5i14x6phhx1axvx0bvqn4ggsimfizs48xbmykgiyfmzkrwgz"; </del> <ins> sha256 = "0ix99da3xd4z200dgvpfc2h1sfx6l8cipichvfjlj39md45grs89"; </ins> }; };


Question: , CVSSv3=5.3 (nixos-20.09) CVSSv3=5.3 (nixos-20.09) Scanned versions: nixos-20.09: . Cc Cc Cc Cc

description = "A tool for managing secrets, this binary includes the UI"; platforms = [ "x86_64-linux" "i686-linux" "x86_64-darwin" "aarch64-linux" ]; license = licenses.mpl20; <del> maintainers = with maintainers; [ offline psyanticy mkaito ]; </del> <ins> maintainers = with maintainers; [ offline psyanticy mkaito Chili-Man ]; </ins> }; }


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

<del> { stdenv, fetchurl, libiconv }: </del> <ins> { lib, stdenv, fetchFromGitHub, autoreconfHook, libiconv }: </ins> stdenv.mkDerivation rec { pname = "wavpack"; <del> version = "5.3.0"; </del> <ins> version = "5.4.0"; </ins> enableParallelBuilding = true; <ins> nativeBuildInputs = [ autoreconfHook ]; </ins> buildInputs = stdenv.lib.optional stdenv.isDarwin libiconv; <del> src = fetchurl { url = "http://www.wavpack.com/${pname}-${version}.tar.bz2"; sha256 = "00baiag7rlkzc6545dqdp4p5sr7xc3n97n7qdkgx58c544x0pw5n"; </del> <ins> src = fetchFromGitHub { owner = "dbry"; repo = "WavPack"; rev = version; sha256 = "1b6szk2vmnqnv5w7h8yc1iazjlidlraq1lwjbmc3fi0snbn6qj44"; </ins> }; <del> meta = with stdenv.lib; { </del> <ins> meta = with lib; { </ins> description = "Hybrid audio compression format"; <del> homepage    = "http://www.wavpack.com/"; </del> <ins> homepage    = "https://www.wavpack.com/"; changelog   = "https://github.com/dbry/WavPack/releases/tag/${version}"; </ins> license     = licenses.bsd3; platforms   = platforms.unix; maintainers = with maintainers; [ codyopel ];


Question:
Describe the bug I believe the source for the package might no longer be valid: Accessing it in the browser shows a 404, and the home page -- -- appears to just be a portal for serving sponsored links. The Wayback Machine shows that the has not been archived since February 2020, and also get the same 404. There was a in Septermber 2020, but I'm unsure if this was the cause. Thanks! To Reproduce Steps to reproduce the behavior: . Expected behavior Installation should not hang, and the font should be installed. Screenshots Additional context appears to be an alternative to Helvetica, so I'm unsure how important this package is. But I figured this error should be documented. As far as I can tell, is the only package using , so if this domain is indeed no longer usable then nothing else should be impacted. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
but the link is also dead: so i would ask there where the font is available and if it is freely licensed now. it was also licensed by adobe at some point it seem to ba available from several shady websites, like but that's clearly illegal and shouldn't be packaged in nixpkgs freely licensed alternatives are: (Nimbus Sans)
I marked this as stale due to inactivity. →
Could the helvetica-neue-lt-std package be removed or at least generate a better error than a 404 when it tries to download the font? I ran into this error while doing a nixos-install so it took a while to find the specific package that was causing my build to fail.
Thank you

{ lib, fetchzip }: let <del> version = "2013.06.07"; # date of most recent file in distribution </del> <ins> version = "2014.08.16"; # date of most recent file in distribution </ins> in fetchzip { name = "helvetica-neue-lt-std-${version}"; <del> url = "http://www.ephifonts.com/downloads/helvetica-neue-lt-std.zip"; </del> <ins> url = "https://web.archive.org/web/20190823153624/http://ephifonts.com/downloads/helvetica-neue-lt-std.zip"; </ins> postFetch = '' mkdir -p $out/share/fonts <del> unzip -j $downloadedFile Helvetica Neue LT Std/*.otf -d $out/share/fonts/opentype </del> <ins> unzip -j $downloadedFile "Helvetica Neue LT Std/*.otf" -d $out/share/fonts/opentype </ins> ''; sha256 = "0ampp9vf9xw0sdppl4lb9i9h75ywljhdcqmzh45mx2x9m7h6xgg9"; <del> meta = { homepage = "http://www.ephifonts.com/free-helvetica-font-helvetica-neue-lt-std.html"; </del> <ins> meta = with lib; { homepage = "https://web.archive.org/web/20190926040940/http://www.ephifonts.com/free-helvetica-font-helvetica-neue-lt-std.html"; </ins> description = "Helvetica Neue LT Std font"; longDescription = '' Helvetica Neue Lt Std is one of the most highly rated and complete


Question:
Describe the bug I believe the source for the package might no longer be valid: Accessing it in the browser shows a 404, and the home page -- -- appears to just be a portal for serving sponsored links. The Wayback Machine shows that the has not been archived since February 2020, and also get the same 404. There was a in Septermber 2020, but I'm unsure if this was the cause. Thanks! To Reproduce Steps to reproduce the behavior: . Expected behavior Installation should not hang, and the font should be installed. Screenshots Additional context appears to be an alternative to Helvetica, so I'm unsure how important this package is. But I figured this error should be documented. As far as I can tell, is the only package using , so if this domain is indeed no longer usable then nothing else should be impacted. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
but the link is also dead: so i would ask there where the font is available and if it is freely licensed now. it was also licensed by adobe at some point it seem to ba available from several shady websites, like but that's clearly illegal and shouldn't be packaged in nixpkgs freely licensed alternatives are: (Nimbus Sans)
I marked this as stale due to inactivity. →
Could the helvetica-neue-lt-std package be removed or at least generate a better error than a 404 when it tries to download the font? I ran into this error while doing a nixos-install so it took a while to find the specific package that was causing my build to fail.
Thank you

font. The numbers are well spaced and defined with high accuracy. The punctuation marks are heavily detailed as well. ''; <del> license = lib.licenses.unfree; maintainers = [ lib.maintainers.romildo ]; platforms = lib.platforms.all; </del> <ins> license = licenses.unfree; platforms = platforms.all; maintainers = with maintainers; [ romildo ]; </ins> }; }


Question:
Describe the bug ! was something changed about the exported package list? Expected behavior same number of packages or even more Additional context we used to have the most packages, but now AUR is on top again
Maybe is part of this.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Might also be a redefinition of a "project" on the repology side, i.e. duplicates that weren't detected before. Projects != Packages. Do we know the revisions of before and after? We could check whether anything went missing from in the tarball because that's the source of Repology's data.
Well it must've happened on January 16th so we could use one commit from the 15th and 17th and see if there are suspicious changes in the that json file in between. Using we can pick a merge commit from the 15th e.g. and one from the 17th e.g.
We need to know the state of the unstable channel on those dates, it's days or sometimes even weeks behind master. Don't really have time for this right now but is probably what we need.
Well it must've happened on January 16th It did appear in Repology on 16. January, but our channel take some time after a commit was done. So i would check like the 9. Jan.. There was a successful channel evaluation on 2021-01-07. Channel evaluation: () packages file: () () () Latest unstable channel evaluation: () So the number of packages decreased by 8,990 between 2021-01-07 () and 2021-01-16 (). There was this change of emacsPackages to on 2021-01-13 () And it's indeed the emacs packages that are missing on 2021-01-16! ! Number of : Number of packages that are in but not in : Full list: For example . It does not exist in packages-2021-02- It does exist today in the search: But not on Repology: We should really be consistent here. The packages that nix can install from nixpkgs channel, and Repology should be identical!
, and so on were moved to their respective interpreters as & in Partly this is to fix the asymmetry of not having package sets available for the packages. The old names now only exists as aliases which probably explains why they have disappeared from Repology. I think this opens up a question regarding if we should remove from . We've tried this before and it makes tools like a lot slower since these package sets are pretty massive. Maybe we should only expose for the default Emacs package but not for the rest? That way we also don't count every package in the sets N times (where N is the number of distinct Emacs packages).
I think such tools should show packages only once, even when they exist for different interpreters like emacs26 and emacs27. But it should be obvious that you can use both. The raw package list should still contain all i guess, so tools like repology get all nixpkgs has to offer. But that is a big topic and it's about UX. For example in the search. Now it looks like this: ! But this would be less cluttered and more user friendly: ! (I opened an issue for that ) Same in .
The bug is probably here: did update the set names here too but I don't think sub-attributes work in that construct.
Nice catch! I've attempted to conjure up a fix in but it needs more testing before I'm comfortable merging.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Status: rPackages is fixed See for example "tidytidbits" on or . In the package set list is also emacs27, but i don't find any packages. When i search for random packages that existed before, like "pony-mode" i don't find it now in search or repology. The name does exist in which is not found in github search, probably because the file is too big. On repology you find only 1 emacs package in nixpkgs! So the package set emacs27 is still missing from .

# Enable recursion into attribute sets that nix-env normally doesn't look into # so that we can get a more complete picture of the available packages for the # purposes of the index. <del> packageOverrides = super: let recurseIntoAttrs = sets: super.lib.genAttrs (builtins.filter (set: builtins.hasAttr set super) sets) (set: super.recurseIntoAttrs (builtins.getAttr set super)); in recurseIntoAttrs [ "roundcubePlugins" "emscriptenfastcompPackages" "fdbPackages" "nodePackages_latest" "nodePackages" "platformioPackages" "haskellPackages" "idrisPackages" "sconsPackages" "gns3Packages" "quicklispPackagesClisp" "quicklispPackagesSBCL" "rPackages" "apacheHttpdPackages_2_4" "zabbix50" "zabbix40" "zabbix30" "fusePackages" "nvidiaPackages" "sourceHanPackages" "atomPackages" "emacs27.pkgs" "steamPackages" "ut2004Packages" "zeroadPackages" ]; </del> <ins> packageOverrides = super: with super; lib.mapAttrs (_: set: recurseIntoAttrs set) { inherit (super) apacheHttpdPackages atomPackages fdbPackages fusePackages gns3Packages haskellPackages idrisPackages nodePackages nodePackages_latest platformioPackages quicklispPackagesClisp quicklispPackagesSBCL rPackages roundcubePlugins sconsPackages sourceHanPackages steamPackages ut2004Packages zabbix40 zabbix50 zeroadPackages ; # This is an alias which we disallow by default; explicitly allow it emacs27Packages = emacs27.pkgs; }; </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: radvd <!-- 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: 2.18 desired version: 2.19 <!-- 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.

stdenv.mkDerivation rec { pname = "radvd"; <del> version = "2.18"; </del> <ins> version = "2.19"; </ins> src = fetchurl { url = "http://www.litech.org/radvd/dist/${pname}-${version}.tar.xz"; <del> sha256 = "1p2wlv3djvla0r84hdncc3wfa530xigs7z9ssc2v5r1pcpzgxgz1"; </del> <ins> sha256 = "0h722f17h7cra1sjgrxhrrvx54mm47fs039909yhbabigxch8kjn"; </ins> }; nativeBuildInputs = [ pkg-config bison flex check ];


Question:
Describe the bug dmd keeps references to boostrap compiler. To Reproduce Steps to reproduce the behavior: Expected behavior dmd has no references to boostrap compiler Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): nixpkgs: Maintainer information: Note: to prevent future regressions, it would be nice to add to the derivation ()
I marked this as stale due to inactivity. →
Still an issue
I marked this as stale due to inactivity. →

{ stdenv , lib , fetchFromGitHub <ins> , removeReferencesTo </ins> , makeWrapper , which , writeTextFile


Question:
Describe the bug dmd keeps references to boostrap compiler. To Reproduce Steps to reproduce the behavior: Expected behavior dmd has no references to boostrap compiler Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): nixpkgs: Maintainer information: Note: to prevent future regressions, it would be nice to add to the derivation ()
I marked this as stale due to inactivity. →
Still an issue
I marked this as stale due to inactivity. →

, installShellFiles , git , unzip <del> , dmd_bin ? "${callPackage ./bootstrap.nix { }}/bin" </del> <ins> , dmdBootstrap ? callPackage ./bootstrap.nix { } , dmd_bin ? "${dmdBootstrap}/bin" </ins> }: let


Question:
Describe the bug dmd keeps references to boostrap compiler. To Reproduce Steps to reproduce the behavior: Expected behavior dmd has no references to boostrap compiler Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): nixpkgs: Maintainer information: Note: to prevent future regressions, it would be nice to add to the derivation ()
I marked this as stale due to inactivity. →
Still an issue
I marked this as stale due to inactivity. →

runHook postInstall ''; <ins> preFixup = '' find $out/bin -type f -exec ${removeReferencesTo}/bin/remove-references-to -t ${dmd_bin}/dmd '{}' + ''; disallowedReferences = [ dmdBootstrap ]; </ins> meta = with lib; { description = "Official reference compiler for the D language"; homepage = "https://dlang.org/";


Question:
Describe the bug The build of the RPI4 image has been broken for a few weeks now. See: The module closure fails to build with: CC Maintainer information:
Caused by See
For the time being, there is no quick way to work around the issue. From the list of available modules, most are needed. We'd need to be able to filter out a module from the list, which AFAIK for lists is impossible with NixOS modules. So uh... annoyingly it'll have to stay this way until some resolution of the overall issue :/... An alternative, but quite intrusive, would be to split the aarch64 profile into an "aarch64 base profile", from which the normal aarch64 and the raspberry pi 4 profiles inherit. Though I don't really like the approach since the raspberry pi 4 profile is, overall, a temporary measure for a somewhat popular and hard-to-work-with platform. It might be more worthwhile , in the long run, to take a final look at 5.10/5.11 mainline and if it is enough to allow a user to bootstrap themselves finally.
couldn't we allow missing kernel modules when generating images at least?
The interface/abstraction for is lacking. The fact it's a list, and lists are really hard to manipulate once set in NixOS modules makes this basically a hard task. I guess augmenting with a (default true) would help. But really what would be required is to tell per module whether it is needed, and allow overriding data. So needs to somehow allow setting "yes/no/optional" per-module, in an ideal world.
Quick idea but what about adding a or something like that and then use setminus as the required kernel modules? Edit: or yeah depending on how it would work using a dictionary?
Using an attrset for availableKernelModules would be the solution. But that breaks existing use cases by default, probably. There might be something coming to handle this issue ; But this is a hard problem to solve correctly AFAIUI. I wouldn't like having the bad abstraction any more than the current breakage that I don't like.
I suggest then to revert the commit that broke this until we have a better abstraction.
I've merged that fixes this issue. Once it you can . You can build it on nixpkgs master using .
I don't think it solved this issue. works around the issue by removing the raspberry pi 4 board-specific image. With merged, the modules are still to the raspberry pi 4 board-specific image, even if they're not present in the kernel build. In fact, there may be more failures! It ends up adding more modules present in mainline, absent from the vendor-specific kernel build.
recommends using the generic image anyway, so that's why I considered it fixed.
Ah sorry, I pre-emptively edited this page. And I'm splitting hair right now because technically the issue is still going on. But really it's all but merged-and-solved.
It appears to still be broken. Booting the latest image from Hydra ( ) results in the image being unable to find /nix/.../init, and failing to continue booting from there.
I've booted the same image and it works. What steps did you take? Mine are:
I performed the same steps, except the last one where I instead used GNOME Disks to write the disk image to the SD card. I don't have a way to reproduce it currently, since the Raspberry Pi 4 I was testing it on, has since been formatted with a different OS to be used in a production system tomorrow. I'll see if I can get my hands on another RPi 4B and perform the same steps again. edit With an exception that I used unzstd instead.
Same, unzip was a typo.
I've gotten my hands on one now for a few minutes, and it appears to be getting an error like: It prints this continually, until I press a key, and are presented with the option to reboot or continue. Continuing kernel panics, and reboot, well, reboots it.
The SD card used is the NOOBs SD card, but overwritten using the command as above, but with the device replaced.
Booting with the same SD card using Ubuntu Server 64bit OS or Ubuntu Core works fine.
It sounds like it "works" up until stage-1, where the kernel is somehow unable to work with the SD card. It might be a combination of that is causing the issue. Do you have other brands SD cards, or same brand but (probably) different batches? It would be helpful to know whether "Ubuntu Server 64bit OS" and "Ubuntu Core" are using the mainline kernel or not. The driver differences might exacerbate issues on marginal hardware.
The underlying issue is now invalid with being merged. I invite you to open an issue, linking to this issue, for your particular problem. It seems you have some kind of hardware-specific issue at first glance.
Thanks, i will test it with other SD cards as well. It appears to only happen with this distribution, but it could certainly still be related to the hardware.
It is likely the other distributions are using the vendor kernel, and that the driver differs in a way where only mainline has a specific issue. Using the "latest kernel" variant of the image may also be something to look into.
I've tried the latest kernel variant as well, but I'll create a new issue with more details once I've collected more information.
I am trying to build NixOS for the raspberry Pi 4 and ran into the same error that started this thread. FWIW, I'm seeing this on nixpkgs and on as well. Would it be prudent to re-open this ticket or file a fresh issue?
please open a new issue and ping this issue with the specific problem you're observing detailed. Please detail what you are attempting to do (e.g. whether it's booting through SD or USB), and as much information as you can. Note that there is a known issue (totally unrelated to this one) about USB boot, ().

<del> { config, ... }: { imports = [ ../sd-card/sd-image-raspberrypi4-installer.nix ]; config = { warnings = [ '' .../cd-dvd/sd-image-raspberrypi4.nix is deprecated and will eventually be removed. Please switch to .../sd-card/sd-image-raspberrypi4-installer.nix, instead. '' ]; }; } </del>


Question:
Describe the bug The build of the RPI4 image has been broken for a few weeks now. See: The module closure fails to build with: CC Maintainer information:
Caused by See
For the time being, there is no quick way to work around the issue. From the list of available modules, most are needed. We'd need to be able to filter out a module from the list, which AFAIK for lists is impossible with NixOS modules. So uh... annoyingly it'll have to stay this way until some resolution of the overall issue :/... An alternative, but quite intrusive, would be to split the aarch64 profile into an "aarch64 base profile", from which the normal aarch64 and the raspberry pi 4 profiles inherit. Though I don't really like the approach since the raspberry pi 4 profile is, overall, a temporary measure for a somewhat popular and hard-to-work-with platform. It might be more worthwhile , in the long run, to take a final look at 5.10/5.11 mainline and if it is enough to allow a user to bootstrap themselves finally.
couldn't we allow missing kernel modules when generating images at least?
The interface/abstraction for is lacking. The fact it's a list, and lists are really hard to manipulate once set in NixOS modules makes this basically a hard task. I guess augmenting with a (default true) would help. But really what would be required is to tell per module whether it is needed, and allow overriding data. So needs to somehow allow setting "yes/no/optional" per-module, in an ideal world.
Quick idea but what about adding a or something like that and then use setminus as the required kernel modules? Edit: or yeah depending on how it would work using a dictionary?
Using an attrset for availableKernelModules would be the solution. But that breaks existing use cases by default, probably. There might be something coming to handle this issue ; But this is a hard problem to solve correctly AFAIUI. I wouldn't like having the bad abstraction any more than the current breakage that I don't like.
I suggest then to revert the commit that broke this until we have a better abstraction.
I've merged that fixes this issue. Once it you can . You can build it on nixpkgs master using .
I don't think it solved this issue. works around the issue by removing the raspberry pi 4 board-specific image. With merged, the modules are still to the raspberry pi 4 board-specific image, even if they're not present in the kernel build. In fact, there may be more failures! It ends up adding more modules present in mainline, absent from the vendor-specific kernel build.
recommends using the generic image anyway, so that's why I considered it fixed.
Ah sorry, I pre-emptively edited this page. And I'm splitting hair right now because technically the issue is still going on. But really it's all but merged-and-solved.
It appears to still be broken. Booting the latest image from Hydra ( ) results in the image being unable to find /nix/.../init, and failing to continue booting from there.
I've booted the same image and it works. What steps did you take? Mine are:
I performed the same steps, except the last one where I instead used GNOME Disks to write the disk image to the SD card. I don't have a way to reproduce it currently, since the Raspberry Pi 4 I was testing it on, has since been formatted with a different OS to be used in a production system tomorrow. I'll see if I can get my hands on another RPi 4B and perform the same steps again. edit With an exception that I used unzstd instead.
Same, unzip was a typo.
I've gotten my hands on one now for a few minutes, and it appears to be getting an error like: It prints this continually, until I press a key, and are presented with the option to reboot or continue. Continuing kernel panics, and reboot, well, reboots it.
The SD card used is the NOOBs SD card, but overwritten using the command as above, but with the device replaced.
Booting with the same SD card using Ubuntu Server 64bit OS or Ubuntu Core works fine.
It sounds like it "works" up until stage-1, where the kernel is somehow unable to work with the SD card. It might be a combination of that is causing the issue. Do you have other brands SD cards, or same brand but (probably) different batches? It would be helpful to know whether "Ubuntu Server 64bit OS" and "Ubuntu Core" are using the mainline kernel or not. The driver differences might exacerbate issues on marginal hardware.
The underlying issue is now invalid with being merged. I invite you to open an issue, linking to this issue, for your particular problem. It seems you have some kind of hardware-specific issue at first glance.
Thanks, i will test it with other SD cards as well. It appears to only happen with this distribution, but it could certainly still be related to the hardware.
It is likely the other distributions are using the vendor kernel, and that the driver differs in a way where only mainline has a specific issue. Using the "latest kernel" variant of the image may also be something to look into.
I've tried the latest kernel variant as well, but I'll create a new issue with more details once I've collected more information.
I am trying to build NixOS for the raspberry Pi 4 and ran into the same error that started this thread. FWIW, I'm seeing this on nixpkgs and on as well. Would it be prudent to re-open this ticket or file a fresh issue?
please open a new issue and ping this issue with the specific problem you're observing detailed. Please detail what you are attempting to do (e.g. whether it's booting through SD or USB), and as much information as you can. Note that there is a known issue (totally unrelated to this one) about USB boot, ().

<del> { imports = [ ../../profiles/installation-device.nix ./sd-image-raspberrypi4.nix ]; # the installation media is also the installation target, # so we don't want to provide the installation configuration.nix. installer.cloneConfig = false; } </del>


Question:
Describe the bug The build of the RPI4 image has been broken for a few weeks now. See: The module closure fails to build with: CC Maintainer information:
Caused by See
For the time being, there is no quick way to work around the issue. From the list of available modules, most are needed. We'd need to be able to filter out a module from the list, which AFAIK for lists is impossible with NixOS modules. So uh... annoyingly it'll have to stay this way until some resolution of the overall issue :/... An alternative, but quite intrusive, would be to split the aarch64 profile into an "aarch64 base profile", from which the normal aarch64 and the raspberry pi 4 profiles inherit. Though I don't really like the approach since the raspberry pi 4 profile is, overall, a temporary measure for a somewhat popular and hard-to-work-with platform. It might be more worthwhile , in the long run, to take a final look at 5.10/5.11 mainline and if it is enough to allow a user to bootstrap themselves finally.
couldn't we allow missing kernel modules when generating images at least?
The interface/abstraction for is lacking. The fact it's a list, and lists are really hard to manipulate once set in NixOS modules makes this basically a hard task. I guess augmenting with a (default true) would help. But really what would be required is to tell per module whether it is needed, and allow overriding data. So needs to somehow allow setting "yes/no/optional" per-module, in an ideal world.
Quick idea but what about adding a or something like that and then use setminus as the required kernel modules? Edit: or yeah depending on how it would work using a dictionary?
Using an attrset for availableKernelModules would be the solution. But that breaks existing use cases by default, probably. There might be something coming to handle this issue ; But this is a hard problem to solve correctly AFAIUI. I wouldn't like having the bad abstraction any more than the current breakage that I don't like.
I suggest then to revert the commit that broke this until we have a better abstraction.
I've merged that fixes this issue. Once it you can . You can build it on nixpkgs master using .
I don't think it solved this issue. works around the issue by removing the raspberry pi 4 board-specific image. With merged, the modules are still to the raspberry pi 4 board-specific image, even if they're not present in the kernel build. In fact, there may be more failures! It ends up adding more modules present in mainline, absent from the vendor-specific kernel build.
recommends using the generic image anyway, so that's why I considered it fixed.
Ah sorry, I pre-emptively edited this page. And I'm splitting hair right now because technically the issue is still going on. But really it's all but merged-and-solved.
It appears to still be broken. Booting the latest image from Hydra ( ) results in the image being unable to find /nix/.../init, and failing to continue booting from there.
I've booted the same image and it works. What steps did you take? Mine are:
I performed the same steps, except the last one where I instead used GNOME Disks to write the disk image to the SD card. I don't have a way to reproduce it currently, since the Raspberry Pi 4 I was testing it on, has since been formatted with a different OS to be used in a production system tomorrow. I'll see if I can get my hands on another RPi 4B and perform the same steps again. edit With an exception that I used unzstd instead.
Same, unzip was a typo.
I've gotten my hands on one now for a few minutes, and it appears to be getting an error like: It prints this continually, until I press a key, and are presented with the option to reboot or continue. Continuing kernel panics, and reboot, well, reboots it.
The SD card used is the NOOBs SD card, but overwritten using the command as above, but with the device replaced.
Booting with the same SD card using Ubuntu Server 64bit OS or Ubuntu Core works fine.
It sounds like it "works" up until stage-1, where the kernel is somehow unable to work with the SD card. It might be a combination of that is causing the issue. Do you have other brands SD cards, or same brand but (probably) different batches? It would be helpful to know whether "Ubuntu Server 64bit OS" and "Ubuntu Core" are using the mainline kernel or not. The driver differences might exacerbate issues on marginal hardware.
The underlying issue is now invalid with being merged. I invite you to open an issue, linking to this issue, for your particular problem. It seems you have some kind of hardware-specific issue at first glance.
Thanks, i will test it with other SD cards as well. It appears to only happen with this distribution, but it could certainly still be related to the hardware.
It is likely the other distributions are using the vendor kernel, and that the driver differs in a way where only mainline has a specific issue. Using the "latest kernel" variant of the image may also be something to look into.
I've tried the latest kernel variant as well, but I'll create a new issue with more details once I've collected more information.
I am trying to build NixOS for the raspberry Pi 4 and ran into the same error that started this thread. FWIW, I'm seeing this on nixpkgs and on as well. Would it be prudent to re-open this ticket or file a fresh issue?
please open a new issue and ping this issue with the specific problem you're observing detailed. Please detail what you are attempting to do (e.g. whether it's booting through SD or USB), and as much information as you can. Note that there is a known issue (totally unrelated to this one) about USB boot, ().

<del> # To build, use: # nix-build nixos -I nixos-config=nixos/modules/installer/sd-card/sd-image-raspberrypi4.nix -A config.system.build.sdImage { config, lib, pkgs, ... }: { imports = [ ./sd-image-aarch64.nix ]; boot.kernelPackages = pkgs.linuxPackages_rpi4; } </del>


Question:
Describe the bug The build of the RPI4 image has been broken for a few weeks now. See: The module closure fails to build with: CC Maintainer information:
Caused by See
For the time being, there is no quick way to work around the issue. From the list of available modules, most are needed. We'd need to be able to filter out a module from the list, which AFAIK for lists is impossible with NixOS modules. So uh... annoyingly it'll have to stay this way until some resolution of the overall issue :/... An alternative, but quite intrusive, would be to split the aarch64 profile into an "aarch64 base profile", from which the normal aarch64 and the raspberry pi 4 profiles inherit. Though I don't really like the approach since the raspberry pi 4 profile is, overall, a temporary measure for a somewhat popular and hard-to-work-with platform. It might be more worthwhile , in the long run, to take a final look at 5.10/5.11 mainline and if it is enough to allow a user to bootstrap themselves finally.
couldn't we allow missing kernel modules when generating images at least?
The interface/abstraction for is lacking. The fact it's a list, and lists are really hard to manipulate once set in NixOS modules makes this basically a hard task. I guess augmenting with a (default true) would help. But really what would be required is to tell per module whether it is needed, and allow overriding data. So needs to somehow allow setting "yes/no/optional" per-module, in an ideal world.
Quick idea but what about adding a or something like that and then use setminus as the required kernel modules? Edit: or yeah depending on how it would work using a dictionary?
Using an attrset for availableKernelModules would be the solution. But that breaks existing use cases by default, probably. There might be something coming to handle this issue ; But this is a hard problem to solve correctly AFAIUI. I wouldn't like having the bad abstraction any more than the current breakage that I don't like.
I suggest then to revert the commit that broke this until we have a better abstraction.
I've merged that fixes this issue. Once it you can . You can build it on nixpkgs master using .
I don't think it solved this issue. works around the issue by removing the raspberry pi 4 board-specific image. With merged, the modules are still to the raspberry pi 4 board-specific image, even if they're not present in the kernel build. In fact, there may be more failures! It ends up adding more modules present in mainline, absent from the vendor-specific kernel build.
recommends using the generic image anyway, so that's why I considered it fixed.
Ah sorry, I pre-emptively edited this page. And I'm splitting hair right now because technically the issue is still going on. But really it's all but merged-and-solved.
It appears to still be broken. Booting the latest image from Hydra ( ) results in the image being unable to find /nix/.../init, and failing to continue booting from there.
I've booted the same image and it works. What steps did you take? Mine are:
I performed the same steps, except the last one where I instead used GNOME Disks to write the disk image to the SD card. I don't have a way to reproduce it currently, since the Raspberry Pi 4 I was testing it on, has since been formatted with a different OS to be used in a production system tomorrow. I'll see if I can get my hands on another RPi 4B and perform the same steps again. edit With an exception that I used unzstd instead.
Same, unzip was a typo.
I've gotten my hands on one now for a few minutes, and it appears to be getting an error like: It prints this continually, until I press a key, and are presented with the option to reboot or continue. Continuing kernel panics, and reboot, well, reboots it.
The SD card used is the NOOBs SD card, but overwritten using the command as above, but with the device replaced.
Booting with the same SD card using Ubuntu Server 64bit OS or Ubuntu Core works fine.
It sounds like it "works" up until stage-1, where the kernel is somehow unable to work with the SD card. It might be a combination of that is causing the issue. Do you have other brands SD cards, or same brand but (probably) different batches? It would be helpful to know whether "Ubuntu Server 64bit OS" and "Ubuntu Core" are using the mainline kernel or not. The driver differences might exacerbate issues on marginal hardware.
The underlying issue is now invalid with being merged. I invite you to open an issue, linking to this issue, for your particular problem. It seems you have some kind of hardware-specific issue at first glance.
Thanks, i will test it with other SD cards as well. It appears to only happen with this distribution, but it could certainly still be related to the hardware.
It is likely the other distributions are using the vendor kernel, and that the driver differs in a way where only mainline has a specific issue. Using the "latest kernel" variant of the image may also be something to look into.
I've tried the latest kernel variant as well, but I'll create a new issue with more details once I've collected more information.
I am trying to build NixOS for the raspberry Pi 4 and ran into the same error that started this thread. FWIW, I'm seeing this on nixpkgs and on as well. Would it be prudent to re-open this ticket or file a fresh issue?
please open a new issue and ping this issue with the specific problem you're observing detailed. Please detail what you are attempting to do (e.g. whether it's booting through SD or USB), and as much information as you can. Note that there is a known issue (totally unrelated to this one) about USB boot, ().

inherit system; }); <del> sd_image_raspberrypi4 = forMatchingSystems [ "aarch64-linux" ] (system: makeSdImage { module = ./modules/installer/sd-card/sd-image-raspberrypi4-installer.nix; inherit system; }); </del> # A bootable VirtualBox virtual appliance as an OVA file (i.e. packaged OVF). ova = forMatchingSystems [ "x86_64-linux" ] (system:


Question:
Stressful Application Test (or stressapptest, its unix name) is a memory interface test. It tries to maximize randomized traffic to memory from processor and I/O, with the intent of creating a realistic high load situation in order to test the existing hardware devices in a computer. It has been used at Google for some time [...] In my experience it's an absolute monster in finding random memory errors that don't show up over weeks of real world usage. Until ECC is commonplace, running this software is necessary. Metadata source URL: license: Apache 2.0 platforms: linux
could you please give a try?
worked no problem, thanks a lot!

<ins> { lib , stdenv , fetchFromGitHub , libaio }: stdenv.mkDerivation rec { pname = "stressapptest"; version = "1.0.9"; src = fetchFromGitHub { owner = pname; repo = pname; rev = "v${version}"; sha256 = "1qzj6h6adx042rb9aiz916jna269whibvj5ys4p5nwdp17fqh922"; }; buildInputs = [ libaio ]; meta = with lib; { description = "Userspace memory and IO stress test tool"; homepage = "https://github.com/stressapptest/stressapptest"; license = with licenses; [ asl20 ]; maintainers = with lib.maintainers; [ fab ]; platforms = platforms.unix; }; } </ins>


Question:
Stressful Application Test (or stressapptest, its unix name) is a memory interface test. It tries to maximize randomized traffic to memory from processor and I/O, with the intent of creating a realistic high load situation in order to test the existing hardware devices in a computer. It has been used at Google for some time [...] In my experience it's an absolute monster in finding random memory errors that don't show up over weeks of real world usage. Until ECC is commonplace, running this software is necessary. Metadata source URL: license: Apache 2.0 platforms: linux
could you please give a try?
worked no problem, thanks a lot!

stress-ng = callPackage ../tools/system/stress-ng { }; <ins> stressapptest = callPackage ../tools/system/stressapptest { }; </ins> stoken = callPackage ../tools/security/stoken (config.stoken or {}); storeBackup = callPackage ../tools/backup/store-backup { };


Question:
Describe the bug When i try to import a config file, i get an error: When i copy the exact same text in , it does work. The file does exist and i can read it, even with the caddy user! So this seem to be a bug. To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Without knowing anything about my first guess would be this: Is it possible this command is evaluating your configuration? If so, the issue is that the command is being run sandboxed so has no access outside the sandbox to your file. Build time commands can be tough.
That would make sense. So NixOS brakes the import feature.
Out of curiosity can you please paste your relevant config?
what exactly do you want to see? For a workaround, i just copied everything into the NixOS option: But in some cases, it's nice to have the webserver config. together with the website sourcecode:
Thanks for posting. The context helps. I think this is what you want:
It could make sense to add an off-by-default option to opt-out build-time configuration check.
Given my above solution, I'm not sure what value it would offer in this scenario. What scenario did you have in mind Can this config file hold secrets maybe?
Then you don't have to use such a workaround on NixOS and can just use it as described in it's documentation. There can be secrets in it, but i don't see how that's relevant here:
Hi, module maintainer here. I was the person who made the original PR for adapting s for Caddy 2, and I had no idea about the directive at the time. The motivation was to generate TLS settings from the module options and merge them with JSON-ified . Please use as suggested for now, and I'll see how I can make this easier in the future.
I marked this as stale due to inactivity. →

let cfg = config.services.caddy; <del> vhostToConfig = vhostName: vhostAttrs: '' ${vhostName} ${builtins.concatStringsSep " " vhostAttrs.serverAliases} { ${vhostAttrs.extraConfig} } ''; configFile = pkgs.writeText "Caddyfile" (builtins.concatStringsSep "n" ([ cfg.config ] ++ (mapAttrsToList vhostToConfig cfg.virtualHosts))); formattedConfig = pkgs.runCommand "formattedCaddyFile" { } '' ${cfg.package}/bin/caddy fmt ${configFile} > $out ''; tlsConfig = { apps.tls.automation.policies = [{ issuers = [{ inherit (cfg) ca email; module = "acme"; }]; }]; }; adaptedConfig = pkgs.runCommand "caddy-config-adapted.json" { } '' ${cfg.package}/bin/caddy adapt  --config ${formattedConfig} --adapter ${cfg.adapter} > $out ''; tlsJSON = pkgs.writeText "tls.json" (builtins.toJSON tlsConfig); # merge the TLS config options we expose with the ones originating in the Caddyfile configJSON = if cfg.ca != null then let tlsConfigMerge = '' {"apps": {"tls": {"automation": {"policies": (if .[0].apps.tls.automation.policies == .[1]?.apps.tls.automation.policies then .[0].apps.tls.automation.policies else (.[0].apps.tls.automation.policies + .[1]?.apps.tls.automation.policies) end) } } } }''; in pkgs.runCommand "caddy-config.json" { } '' ${pkgs.jq}/bin/jq -s '.[0] * ${tlsConfigMerge}' ${adaptedConfig} ${tlsJSON} > $out </del> <ins> virtualHosts = attrValues cfg.virtualHosts; acmeVHosts = filter (hostOpts: hostOpts.useACMEHost != null) virtualHosts; mkVHostConf = hostOpts: let sslCertDir = config.security.acme.certs.${hostOpts.useACMEHost}.directory; in </ins> '' <del> else adaptedConfig; </del> <ins> ${hostOpts.hostName} ${concatStringsSep " " hostOpts.serverAliases} { bind ${concatStringsSep " " hostOpts.listenAddresses} ${optionalString (hostOpts.useACMEHost != null) "tls ${sslCertDir}/cert.pem ${sslCertDir}/key.pem"} log { ${hostOpts.logFormat} } ${hostOpts.extraConfig} } ''; configFile = let Caddyfile = pkgs.writeText "Caddyfile" '' { ${optionalString (cfg.email != null) "email ${cfg.email}"} ${optionalString (cfg.acmeCA != null) "acme_ca ${cfg.acmeCA}"} log { ${cfg.logFormat} } } ${cfg.extraConfig} ''; Caddyfile-formatted = pkgs.runCommand "Caddyfile-formatted" { nativeBuildInputs = [ cfg.package ]; } '' ${cfg.package}/bin/caddy fmt ${Caddyfile} > $out ''; in if pkgs.stdenv.buildPlatform == pkgs.stdenv.hostPlatform then Caddyfile-formatted else Caddyfile; </ins> in { imports = [ (mkRemovedOptionModule [ "services" "caddy" "agree" ] "this option is no longer necessary for Caddy 2") <ins> (mkRenamedOptionModule [ "services" "caddy" "ca" ] [ "services" "caddy" "acmeCA" ]) (mkRenamedOptionModule [ "services" "caddy" "config" ] [ "services" "caddy" "extraConfig" ]) </ins> ]; <ins> # interface </ins> options.services.caddy = { enable = mkEnableOption "Caddy web server"; <del> config = mkOption { default = ""; example = '' example.com { encode gzip log root /srv/http } </del> <ins> user = mkOption { default = "caddy"; type = types.str; description = '' User account under which caddy runs. <note><para> If left as the default value this user will automatically be created on system activation, otherwise you are responsible for ensuring the user exists before the Caddy service starts. </para></note> </ins> ''; <del> type = types.lines; </del> <ins> }; group = mkOption { default = "caddy"; type = types.str; </ins> description = '' <del> Verbatim Caddyfile to use. Caddy v2 supports multiple config formats via adapters (see <option>services.caddy.adapter</option>). </del> <ins> Group account under which caddy runs. <note><para> If left as the default value this user will automatically be created on system activation, otherwise you are responsible for ensuring the user exists before the Caddy service starts. </para></note> </ins> ''; }; <del> virtualHosts = mkOption { type = types.attrsOf (types.submodule (import ./vhost-options.nix { inherit config lib; })); default = { }; example = literalExpression '' { "hydra.example.com" = { serverAliases = [ "www.hydra.example.com" ]; extraConfig = '''''' encode gzip log root /srv/http ''''''; }; }; </del> <ins> package = mkOption { default = pkgs.caddy; defaultText = literalExpression "pkgs.caddy"; type = types.package; description = '' Caddy package to use. </ins> ''; <del> description = "Declarative vhost config"; </del> }; <ins> dataDir = mkOption { type = types.path; default = "/var/lib/caddy"; description = '' The data directory for caddy. </ins> <del> user = mkOption { default = "caddy"; type = types.str; description = "User account under which caddy runs."; </del> <ins> <note> <para> If left as the default value this directory will automatically be created before the Caddy server starts, otherwise you are responsible for ensuring the directory exists with appropriate ownership and permissions. </para> <para> Caddy v2 replaced <literal>CADDYPATH</literal> with XDG directories. See <link xlink:href="https://caddyserver.com/docs/conventions#file-locations"/>. </para> </note> ''; </ins> }; <del> group = mkOption { default = "caddy"; type = types.str; description = "Group account under which caddy runs."; </del> <ins> logDir = mkOption { type = types.path; default = "/var/log/caddy"; description = '' Directory for storing Caddy access logs. <note><para> If left as the default value this directory will automatically be created before the Caddy server starts, otherwise the sysadmin is responsible for ensuring the directory exists with appropriate ownership and permissions. </para></note> ''; }; logFormat = mkOption { type = types.lines; default = '' level ERROR ''; example = literalExpression '' mkForce "level INFO"; ''; description = '' Configuration for the default logger. See <link xlink:href="https://caddyserver.com/docs/caddyfile/options#log"/> for details. ''; }; configFile = mkOption { type = types.path; default = configFile; defaultText = "A Caddyfile automatically generated by values from services.caddy.*"; example = literalExpression '' pkgs.writeText "Caddyfile" ''' example.com root * /var/www/wordpress php_fastcgi unix//run/php/php-version-fpm.sock file_server '''; ''; description = '' Override the configuration file used by Caddy. By default, NixOS generates one automatically. ''; </ins> }; adapter = mkOption {


Question:
Describe the bug When i try to import a config file, i get an error: When i copy the exact same text in , it does work. The file does exist and i can read it, even with the caddy user! So this seem to be a bug. To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Without knowing anything about my first guess would be this: Is it possible this command is evaluating your configuration? If so, the issue is that the command is being run sandboxed so has no access outside the sandbox to your file. Build time commands can be tough.
That would make sense. So NixOS brakes the import feature.
Out of curiosity can you please paste your relevant config?
what exactly do you want to see? For a workaround, i just copied everything into the NixOS option: But in some cases, it's nice to have the webserver config. together with the website sourcecode:
Thanks for posting. The context helps. I think this is what you want:
It could make sense to add an off-by-default option to opt-out build-time configuration check.
Given my above solution, I'm not sure what value it would offer in this scenario. What scenario did you have in mind Can this config file hold secrets maybe?
Then you don't have to use such a workaround on NixOS and can just use it as described in it's documentation. There can be secrets in it, but i don't see how that's relevant here:
Hi, module maintainer here. I was the person who made the original PR for adapting s for Caddy 2, and I had no idea about the directive at the time. The motivation was to generate TLS settings from the module options and merge them with JSON-ified . Please use as suggested for now, and I'll see how I can make this easier in the future.
I marked this as stale due to inactivity. →

type = types.str; description = '' Name of the config adapter to use. <del> See https://caddyserver.com/docs/config-adapters for the full list. </del> <ins> See <link xlink:href="https://caddyserver.com/docs/config-adapters"/> for the full list. <note><para> Any value other than <literal>caddyfile</literal> is only valid when providing your own <option>configFile</option>. </para></note> </ins> ''; };


Question:
Describe the bug When i try to import a config file, i get an error: When i copy the exact same text in , it does work. The file does exist and i can read it, even with the caddy user! So this seem to be a bug. To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Without knowing anything about my first guess would be this: Is it possible this command is evaluating your configuration? If so, the issue is that the command is being run sandboxed so has no access outside the sandbox to your file. Build time commands can be tough.
That would make sense. So NixOS brakes the import feature.
Out of curiosity can you please paste your relevant config?
what exactly do you want to see? For a workaround, i just copied everything into the NixOS option: But in some cases, it's nice to have the webserver config. together with the website sourcecode:
Thanks for posting. The context helps. I think this is what you want:
It could make sense to add an off-by-default option to opt-out build-time configuration check.
Given my above solution, I'm not sure what value it would offer in this scenario. What scenario did you have in mind Can this config file hold secrets maybe?
Then you don't have to use such a workaround on NixOS and can just use it as described in it's documentation. There can be secrets in it, but i don't see how that's relevant here:
Hi, module maintainer here. I was the person who made the original PR for adapting s for Caddy 2, and I had no idea about the directive at the time. The motivation was to generate TLS settings from the module options and merge them with JSON-ified . Please use as suggested for now, and I'll see how I can make this easier in the future.
I marked this as stale due to inactivity. →

default = false; type = types.bool; description = '' <del> Use saved config, if any (and prefer over configuration passed with <option>services.caddy.config</option>). </del> <ins> Use saved config, if any (and prefer over any specified configuration passed with <literal>--config</literal>). </ins> ''; }; <del> ca = mkOption { default = "https://acme-v02.api.letsencrypt.org/directory"; example = "https://acme-staging-v02.api.letsencrypt.org/directory"; type = types.nullOr types.str; </del> <ins> extraConfig = mkOption { type = types.lines; default = ""; example = '' example.com { encode gzip log root /srv/http } ''; </ins> description = '' <del> Certificate authority ACME server. The default (Let's Encrypt production server) should be fine for most people. Set it to null if you don't want to include any authority (or if you want to write a more fine-graned configuration manually) </del> <ins> Additional lines of configuration appended to the automatically generated <literal>Caddyfile</literal>. </ins> ''; }; <del> email = mkOption { default = ""; type = types.str; description = "Email address (for Let's Encrypt certificate)"; </del> <ins> virtualHosts = mkOption { type = with types; attrsOf (submodule (import ./vhost-options.nix { inherit cfg; })); default = {}; example = literalExpression '' { "hydra.example.com" = { serverAliases = [ "www.hydra.example.com" ]; extraConfig = ''' encode gzip root /srv/http '''; }; }; ''; description = '' Declarative specification of virtual hosts served by Caddy. ''; </ins> }; <del> dataDir = mkOption { default = "/var/lib/caddy"; type = types.path; </del> <ins> acmeCA = mkOption { default = "https://acme-v02.api.letsencrypt.org/directory"; example = "https://acme-staging-v02.api.letsencrypt.org/directory"; type = with types; nullOr str; </ins> description = '' <del> The data directory, for storing certificates. Before 17.09, this would create a .caddy directory. With 17.09 the contents of the .caddy directory are in the specified data directory instead. </del> <ins> The URL to the ACME CA's directory. It is strongly recommended to set this to Let's Encrypt's staging endpoint for testing or development. </ins> <del> Caddy v2 replaced CADDYPATH with XDG directories. See https://caddyserver.com/docs/conventions#file-locations. </del> <ins> Set it to <literal>null</literal> if you want to write a more fine-grained configuration manually. </ins> ''; }; <del> package = mkOption { default = pkgs.caddy; defaultText = literalExpression "pkgs.caddy"; type = types.package; </del> <ins> email = mkOption { default = null; type = with types; nullOr str; </ins> description = '' <del> Caddy package to use. </del> <ins> Your email address. Mainly used when creating an ACME account with your CA, and is highly recommended in case there are problems with your certificates. </ins> ''; }; }; <ins> # implementation </ins> config = mkIf cfg.enable { <ins> assertions = [ { assertion = cfg.adapter != "caddyfile" -> cfg.configFile != configFile; message = "Any value other than 'caddyfile' is only valid when providing your own `services.caddy.configFile`"; } ]; services.caddy.extraConfig = concatMapStringsSep "n" mkVHostConf virtualHosts; </ins> systemd.packages = [ cfg.package ]; systemd.services.caddy = { <ins> wants = map (hostOpts: "acme-finished-${hostOpts.useACMEHost}.target") acmeVHosts; after = map (hostOpts: "acme-selfsigned-${hostOpts.useACMEHost}.service") acmeVHosts; before = map (hostOpts: "acme-${hostOpts.useACMEHost}.service") acmeVHosts; </ins> wantedBy = [ "multi-user.target" ]; startLimitIntervalSec = 14400; startLimitBurst = 10;


Question:
Describe the bug When i try to import a config file, i get an error: When i copy the exact same text in , it does work. The file does exist and i can read it, even with the caddy user! So this seem to be a bug. To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Without knowing anything about my first guess would be this: Is it possible this command is evaluating your configuration? If so, the issue is that the command is being run sandboxed so has no access outside the sandbox to your file. Build time commands can be tough.
That would make sense. So NixOS brakes the import feature.
Out of curiosity can you please paste your relevant config?
what exactly do you want to see? For a workaround, i just copied everything into the NixOS option: But in some cases, it's nice to have the webserver config. together with the website sourcecode:
Thanks for posting. The context helps. I think this is what you want:
It could make sense to add an off-by-default option to opt-out build-time configuration check.
Given my above solution, I'm not sure what value it would offer in this scenario. What scenario did you have in mind Can this config file hold secrets maybe?
Then you don't have to use such a workaround on NixOS and can just use it as described in it's documentation. There can be secrets in it, but i don't see how that's relevant here:
Hi, module maintainer here. I was the person who made the original PR for adapting s for Caddy 2, and I had no idea about the directive at the time. The motivation was to generate TLS settings from the module options and merge them with JSON-ified . Please use as suggested for now, and I'll see how I can make this easier in the future.
I marked this as stale due to inactivity. →

serviceConfig = { # https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStart= # If the empty string is assigned to this option, the list of commands to start is reset, prior assignments of this option will have no effect. <del> ExecStart = [ "" "${cfg.package}/bin/caddy run ${optionalString cfg.resume "--resume"} --config ${configJSON}" ]; ExecReload = [ "" "${cfg.package}/bin/caddy reload --config ${configJSON}" ]; </del> <ins> ExecStart = [ "" "${cfg.package}/bin/caddy run --config ${cfg.configFile} --adapter ${cfg.adapter} ${optionalString cfg.resume "--resume"}" ]; ExecReload = [ "" "${cfg.package}/bin/caddy reload --config ${cfg.configFile} --adapter ${cfg.adapter}" ]; ExecStartPre = "${cfg.package}/bin/caddy validate --config ${cfg.configFile} --adapter ${cfg.adapter}"; </ins> User = cfg.user; Group = cfg.group; ReadWriteDirectories = cfg.dataDir; <ins> StateDirectory = mkIf (cfg.dataDir == "/var/lib/caddy") [ "caddy" ]; LogsDirectory = mkIf (cfg.logDir == "/var/log/caddy") [ "caddy" ]; </ins> Restart = "on-abnormal"; <ins> SupplementaryGroups = mkIf (length acmeVHosts != 0) [ "acme" ]; </ins> # TODO: attempt to upstream these options NoNewPrivileges = true;


Question:
Describe the bug When i try to import a config file, i get an error: When i copy the exact same text in , it does work. The file does exist and i can read it, even with the caddy user! So this seem to be a bug. To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Without knowing anything about my first guess would be this: Is it possible this command is evaluating your configuration? If so, the issue is that the command is being run sandboxed so has no access outside the sandbox to your file. Build time commands can be tough.
That would make sense. So NixOS brakes the import feature.
Out of curiosity can you please paste your relevant config?
what exactly do you want to see? For a workaround, i just copied everything into the NixOS option: But in some cases, it's nice to have the webserver config. together with the website sourcecode:
Thanks for posting. The context helps. I think this is what you want:
It could make sense to add an off-by-default option to opt-out build-time configuration check.
Given my above solution, I'm not sure what value it would offer in this scenario. What scenario did you have in mind Can this config file hold secrets maybe?
Then you don't have to use such a workaround on NixOS and can just use it as described in it's documentation. There can be secrets in it, but i don't see how that's relevant here:
Hi, module maintainer here. I was the person who made the original PR for adapting s for Caddy 2, and I had no idea about the directive at the time. The motivation was to generate TLS settings from the module options and merge them with JSON-ified . Please use as suggested for now, and I'll see how I can make this easier in the future.
I marked this as stale due to inactivity. →

group = cfg.group; uid = config.ids.uids.caddy; home = cfg.dataDir; <del> createHome = true; </del> }; };


Question:
Describe the bug When i try to import a config file, i get an error: When i copy the exact same text in , it does work. The file does exist and i can read it, even with the caddy user! So this seem to be a bug. To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Without knowing anything about my first guess would be this: Is it possible this command is evaluating your configuration? If so, the issue is that the command is being run sandboxed so has no access outside the sandbox to your file. Build time commands can be tough.
That would make sense. So NixOS brakes the import feature.
Out of curiosity can you please paste your relevant config?
what exactly do you want to see? For a workaround, i just copied everything into the NixOS option: But in some cases, it's nice to have the webserver config. together with the website sourcecode:
Thanks for posting. The context helps. I think this is what you want:
It could make sense to add an off-by-default option to opt-out build-time configuration check.
Given my above solution, I'm not sure what value it would offer in this scenario. What scenario did you have in mind Can this config file hold secrets maybe?
Then you don't have to use such a workaround on NixOS and can just use it as described in it's documentation. There can be secrets in it, but i don't see how that's relevant here:
Hi, module maintainer here. I was the person who made the original PR for adapting s for Caddy 2, and I had no idea about the directive at the time. The motivation was to generate TLS settings from the module options and merge them with JSON-ified . Please use as suggested for now, and I'll see how I can make this easier in the future.
I marked this as stale due to inactivity. →

caddy.gid = config.ids.gids.caddy; }; <ins> security.acme.certs = let eachACMEHost = unique (catAttrs "useACMEHost" acmeVHosts); reloads = map (useACMEHost: nameValuePair useACMEHost { reloadServices = [ "caddy.service" ]; }) eachACMEHost; in listToAttrs reloads; </ins> }; }


Question:
Describe the bug When i try to import a config file, i get an error: When i copy the exact same text in , it does work. The file does exist and i can read it, even with the caddy user! So this seem to be a bug. To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Without knowing anything about my first guess would be this: Is it possible this command is evaluating your configuration? If so, the issue is that the command is being run sandboxed so has no access outside the sandbox to your file. Build time commands can be tough.
That would make sense. So NixOS brakes the import feature.
Out of curiosity can you please paste your relevant config?
what exactly do you want to see? For a workaround, i just copied everything into the NixOS option: But in some cases, it's nice to have the webserver config. together with the website sourcecode:
Thanks for posting. The context helps. I think this is what you want:
It could make sense to add an off-by-default option to opt-out build-time configuration check.
Given my above solution, I'm not sure what value it would offer in this scenario. What scenario did you have in mind Can this config file hold secrets maybe?
Then you don't have to use such a workaround on NixOS and can just use it as described in it's documentation. There can be secrets in it, but i don't see how that's relevant here:
Hi, module maintainer here. I was the person who made the original PR for adapting s for Caddy 2, and I had no idea about the directive at the time. The motivation was to generate TLS settings from the module options and merge them with JSON-ified . Please use as suggested for now, and I'll see how I can make this easier in the future.
I marked this as stale due to inactivity. →

<del> # This file defines the options that can be used both for the Nginx # main server configuration, and for the virtual hosts.  (The latter # has additional options that affect the web server as a whole, like # the user/group to run under.) { lib, ... }: with lib; </del> <ins> { cfg }: { config, lib, name, ... }: let inherit (lib) literalExpression mkOption types; in </ins> { options = { <ins> hostName = mkOption { type = types.str; default = name; description = "Canonical hostname for the server."; }; </ins> serverAliases = mkOption { <del> type = types.listOf types.str; </del> <ins> type = with types; listOf str; </ins> default = [ ]; example = [ "www.example.org" "example.org" ]; description = ''


Question:
Describe the bug When i try to import a config file, i get an error: When i copy the exact same text in , it does work. The file does exist and i can read it, even with the caddy user! So this seem to be a bug. To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Without knowing anything about my first guess would be this: Is it possible this command is evaluating your configuration? If so, the issue is that the command is being run sandboxed so has no access outside the sandbox to your file. Build time commands can be tough.
That would make sense. So NixOS brakes the import feature.
Out of curiosity can you please paste your relevant config?
what exactly do you want to see? For a workaround, i just copied everything into the NixOS option: But in some cases, it's nice to have the webserver config. together with the website sourcecode:
Thanks for posting. The context helps. I think this is what you want:
It could make sense to add an off-by-default option to opt-out build-time configuration check.
Given my above solution, I'm not sure what value it would offer in this scenario. What scenario did you have in mind Can this config file hold secrets maybe?
Then you don't have to use such a workaround on NixOS and can just use it as described in it's documentation. There can be secrets in it, but i don't see how that's relevant here:
Hi, module maintainer here. I was the person who made the original PR for adapting s for Caddy 2, and I had no idea about the directive at the time. The motivation was to generate TLS settings from the module options and merge them with JSON-ified . Please use as suggested for now, and I'll see how I can make this easier in the future.
I marked this as stale due to inactivity. →

''; }; <ins> listenAddresses = mkOption { type = with types; listOf str; description = '' A list of host interfaces to bind to for this virtual host. ''; default = [ ]; example = [ "127.0.0.1" "::1" ]; }; useACMEHost = mkOption { type = types.nullOr types.str; default = null; description = '' A host of an existing Let's Encrypt certificate to use. This is mostly useful if you use DNS challenges but Caddy does not currently support your provider. <emphasis>Note that this option does not create any certificates, nor does it add subdomains to existing ones – you will need to create them manually using <xref linkend="opt-security.acme.certs"/>. Additionally, you should probably add the <literal>caddy</literal> user to the <literal>acme</literal> group to grant access to the certificates.</emphasis> ''; }; logFormat = mkOption { type = types.lines; default = '' output file ${cfg.logDir}/access-${config.hostName}.log ''; defaultText = '' output file ''${config.services.caddy.logDir}/access-''${hostName}.log ''; example = literalExpression '' mkForce ''' output discard '''; ''; description = '' Configuration for HTTP request logging (also known as access logs). See <link xlink:href="https://caddyserver.com/docs/caddyfile/directives/log#log"/> for details. ''; }; </ins> extraConfig = mkOption { type = types.lines; default = ""; description = '' <del> These lines go into the vhost verbatim </del> <ins> Additional lines of configuration appended to this virtual host in the automatically generated <literal>Caddyfile</literal>. </ins> ''; }; }; }


Question:
Describe the bug While building the minimal installation iso without using the cache, building smartmontools on fails with: Indeed looking at it looks like the URL should be and indeed produces 11n54ycsy512q4linczzj1x3dyj0q4zvh928rq3lqnkg9jh0kbiv This was in and seemed fine at that point.
the difference between the cached and the downloaded file is:

let version = "7.2"; <del> dbrev = "5164"; </del> <ins> dbrev = "5171"; </ins> drivedbBranch = "RELEASE_7_2_DRIVEDB"; driverdb = fetchurl { url    = "https://sourceforge.net/p/smartmontools/code/${dbrev}/tree/branches/${drivedbBranch}/smartmontools/drivedb.h?format=raw"; <del> sha256 = "1vj0sv3bgcd0lwk5x450brfyxksa5fn1mjgvmj994ab8spmicc43"; </del> <ins> sha256 = "0vncr98xagbcfsxgfgxsip2qrl9q3y8va19qhv6yknlwbdfap4mn"; </ins> name   = "smartmontools-drivedb.h"; };


Question:
Describe the bug A clear and concise description of what the bug is. To Reproduce build e.g. or Notify maintainers Metadata Please run and paste the result. Maintainer information:
I marked this as stale due to inactivity. →
pkgsCross.aarch64-multiplatform.perlPackages.PkgConfig still fails with the same error on
Had a quick look: Seems like PkgConfig depends on File::Glob::bsdglob during build (which uses miniperl). Maybe adding a for wrapping to in perl-cross is the way to go? PS: I'm not sure if this is the correct approach, not very familiar with cross compilation. Any ideas on how to fix?
considering the failure in the here actually comes from a failing , so a simple fix might be this: This has allowed me to cross-build on x86_64-linux: I'll post a PR shortly for your review :muscle:
As a follow up, the resulting / scripts seem to work: (I have multiarch exec via and enabled BTW)

}; }; <del> PkgConfig = buildPerlPackage { </del> <ins> PkgConfig = buildPerlPackage rec { </ins> pname = "PkgConfig"; version = "0.25026"; src = fetchurl { url = "mirror://cpan/authors/id/P/PL/PLICEASE/PkgConfig-0.25026.tar.gz"; sha256 = "1862hzlkibqsgynrnwg43acycp4rlsv19gsybjwq39nnqb9mxfjd"; }; <ins> # support cross-compilation by simplifying the way we get version during build postPatch = '' substituteInPlace Makefile.PL --replace  'do { require "./lib/PkgConfig.pm"; $PkgConfig::VERSION; }'  '"${version}"' ''; </ins> meta = { description = "Pure-Perl Core-Only replacement for pkg-config"; license = with lib.licenses; [ artistic1 gpl1Plus ];


Question:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also:
CVE details indicate that is vulnerable until version (included), which is the version we have in . Version seems to be the latest available: .
I'm actually wondering why this issue was created. We have thrift 0.13 in both unstable and 20.09. Closing and debugging my code...
I think the issue was rightfully created: it says INCLUDED!

license = licenses.asl20; platforms = platforms.linux ++ platforms.darwin; maintainers = [ maintainers.bjornfor ]; <ins> knownVulnerabilities = [ "CVE-2018-1320" "CVE-2018-11798" "CVE-2019-0205" "CVE-2019-0210" "CVE-2020-13949" ]; </ins> }; }


Question:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also:
CVE details indicate that is vulnerable until version (included), which is the version we have in . Version seems to be the latest available: .
I'm actually wondering why this issue was created. We have thrift 0.13 in both unstable and 20.09. Closing and debugging my code...
I think the issue was rightfully created: it says INCLUDED!

license = licenses.asl20; platforms = platforms.linux ++ platforms.darwin; maintainers = [ maintainers.bjornfor ]; <ins> knownVulnerabilities = [ "CVE-2020-13949" ]; </ins> }; }


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


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


Question:
Project description Flawfinder is a simple program that scans C/C++ source code and reports potential security flaws. It can be a useful tool for examining software for vulnerabilities, and it can also serve as a simple introduction to static source code analysis tools more generally. It is designed to be easy to install and use. Flawfinder supports the Common Weakness Enumeration (CWE) and is officially CWE-Compatible. Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux, darwin
could you please test Thanks
Works for me on NixOS. I wrote a simple c program that it found the vuln in: where it gave:

<ins> { lib , stdenv , fetchurl , installShellFiles , python3 }: stdenv.mkDerivation rec { pname = "flawfinder"; version = "2.0.15"; src = fetchurl { url = "https://dwheeler.com/flawfinder/flawfinder-${version}.tar.gz"; sha256 = "01j4szy8gwvikrfzfayfayjnc1za0jxsnxp5fsa6d06kn69wyr8a"; }; nativeBuildInputs = [ installShellFiles ]; buildInputs = [ python3 ]; installPhase = '' runHook preInstall mkdir -p $out/bin cp ${pname} $out/bin installManPage flawfinder.1 runHook postInstall ''; meta = with lib; { description = "Tool to examines C/C++ source code for security flaws"; homepage = "https://dwheeler.com/flawfinder/"; license = with licenses; [ gpl2Only ]; maintainers = with maintainers; [ fab ]; }; } </ins>


Question:
Project description Flawfinder is a simple program that scans C/C++ source code and reports potential security flaws. It can be a useful tool for examining software for vulnerabilities, and it can also serve as a simple introduction to static source code analysis tools more generally. It is designed to be easy to install and use. Flawfinder supports the Common Weakness Enumeration (CWE) and is officially CWE-Compatible. Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux, darwin
could you please test Thanks
Works for me on NixOS. I wrote a simple c program that it found the vuln in: where it gave:

flamegraph = callPackage ../development/tools/flamegraph { }; <ins> flawfinder = callPackage ../development/tools/flawfinder { }; </ins> flips = callPackage ../tools/compression/flips { }; fmbt = callPackage ../development/tools/fmbt {


Question:
Describe the bug I switched from to on KDE. But the audio control tray icon is gone. Media keys don't work either. Note that can adjust audio volume and switching devices without issue. Audio output is also fine. Not sure it's an issue from KDE or pipewire side. Here is my configuration: and are both running. The latter one has some error but still running as well. To Reproduce Steps to reproduce the behavior: X11 and KDE. sound configuration above. , log out and re-log in. audio icon in system tray is gone. Media keys don't work any more. Expected behavior Audio control from KDE and media keys all work. Screenshots ! Additional context Also mentioned in <!-- 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:
I believe the solution is just to have and installed, so you can install them manually for now and that should work.
I switched to pipewire some time ago and subsequently forgot all about it (things just worked) and I haven't had the tray icon disappear at any point. I cannot comment on media keys. Keyboard doesn't have them.
After adding and into , and a reboot. The tray icon appears in a wired state. There are two forever-muted icon shown. One prompts the original "Audio Volume" window, but shows . Though the audio plays well. ! Another prompts a small window shows several volume slider. The "Master" has no effect, but per-application control works. (Another strange thing. When opening this window, any shortcut of KDE doesn't work anymore, including my screenshot key and ) ! Pressing any media key including toggle mute, increase and decrease volume keys, always shows a "Audio Muted" tip.
Note that doesn't work anymore after updating to current nixos-unstable . It shows "Establishing connection to PulseAudio. Please Wait..." forever, while are just running fine. Not sure if it is caused by the pipewire version bump
Sidenote: should be removed from your config, according to . I think it enables ALSA. Kind of annoying, but similar to how should be false if using .
Tried but it made no difference.
Works fine for me on current unstable with and installed through home-manager. I have the pipewire setup in .
I'm using pure pulseaudio facing the same problem. After installing kmix and plasma-pa, I also get two audio icons and the other situations like the picture. I believe one of the is for the original plasma which is muted and the other is from kmix. By the way, I'm on an old laptop and the media key is not working until I installed kmix.
Sorry for necroposting. Any updates on this? I have this problem too.

++ lib.optionals config.hardware.bluetooth.enable [ bluedevil bluez-qt pkgs.openobex pkgs.obexftp ] ++ lib.optional config.networking.networkmanager.enable plasma-nm ++ lib.optional config.hardware.pulseaudio.enable plasma-pa <ins> ++ lib.optional config.services.pipewire.pulse.enable plasma-pa </ins> ++ lib.optional config.powerManagement.enable powerdevil ++ lib.optional config.services.colord.enable pkgs.colord-kde ++ lib.optionals config.services.samba.enable [ kdenetwork-filesharing pkgs.samba ]


Question: Describe the bug fava does not build on master since the merge of staging-next in : To Reproduce Steps to reproduce the behavior: -env -f ~/code/nixpkgs -iA fava Notify maintainers hi

}; checkInputs = [ python3.pkgs.pytest ]; <ins> nativeBuildInputs = with python3.pkgs; [ setuptools-scm ]; </ins> propagatedBuildInputs = with python3.pkgs; [ Babel


Question: Project description The recoll package exposes a python API. It'd be awesome to have a package for that. Metadata homepage URL: related: source URL: Main package already exists - platforms: unix

++ lib.optionals (!withGui) [ "--disable-qtgui" "--disable-x11mon" ] ++ (if stdenv.isLinux then [ "--with-inotify" ] else [ "--without-inotify" ]); <del> nativeBuildInputs = [ pkg-config ]; </del> <ins> nativeBuildInputs = [ file pkg-config python3Packages.setuptools which ]; </ins> <del> buildInputs = with python3Packages; [ bison chmlib file python setuptools which xapian zlib </del> <ins> buildInputs = [ bison chmlib python3Packages.python xapian zlib </ins> ] ++ lib.optional withGui qtbase ++ lib.optional stdenv.isDarwin libiconv;


Question: Project description The recoll package exposes a python API. It'd be awesome to have a package for that. Metadata homepage URL: related: source URL: Main package already exists - platforms: unix

homepage = "https://www.lesbonscomptes.com/recoll/"; license = licenses.gpl2; platforms = platforms.unix; <del> maintainers = [ maintainers.jcumming ]; </del> <ins> maintainers = with maintainers; [ jcumming kiyengar ]; </ins> }; }


Question: Project description The recoll package exposes a python API. It'd be awesome to have a package for that. Metadata homepage URL: related: source URL: Main package already exists - platforms: unix

recaptcha_client = callPackage ../development/python-modules/recaptcha_client { }; <ins> recoll = disabledIf (!isPy3k) (toPythonModule (pkgs.recoll.override { python3Packages = self; })); </ins> recommonmark = callPackage ../development/python-modules/recommonmark { }; redbaron = callPackage ../development/python-modules/redbaron { };


Question:
Describe the bug Upon enabling docker via sysctl.d is not updated to allow IP forwarding which is required by containers to communicate with outside world. To Reproduce Steps to reproduce the behavior: This will get up and running with set to which in my understanding is set by the itself. to re-apply system-wide sysctl settings and check By now your bridge-mode docker containers lost connectivity. Expected behavior I expect to override relevant values. Something like this: Additional context I discovered this problem when applying other sysctl values on a running system without a reboot. Notify maintainers Metadata
Hi, I stumbled into the same issue. I had to manually run to regain container internet access.

config = mkIf cfg.enable (mkMerge [{ boot.kernelModules = [ "bridge" "veth" ]; <ins> boot.kernel.sysctl = { "net.ipv4.conf.all.forwarding" = mkOverride 99 true; "net.ipv4.conf.default.forwarding" = mkOverride 99 true; }; </ins> environment.systemPackages = [ cfg.package ] ++ optional cfg.enableNvidia pkgs.nvidia-docker; users.groups.docker.gid = config.ids.gids.docker;


Question:
Describe the bug Upon enabling docker via sysctl.d is not updated to allow IP forwarding which is required by containers to communicate with outside world. To Reproduce Steps to reproduce the behavior: This will get up and running with set to which in my understanding is set by the itself. to re-apply system-wide sysctl settings and check By now your bridge-mode docker containers lost connectivity. Expected behavior I expect to override relevant values. Something like this: Additional context I discovered this problem when applying other sysctl values on a running system without a reboot. Notify maintainers Metadata
Hi, I stumbled into the same issue. I had to manually run to regain container internet access.

# Must match version 4 times to ensure client and server git commits and versions are correct docker.succeed('[ $(docker version | grep ${pkgs.docker.version} | wc -l) = "4" ]') <ins> docker.succeed("systemctl restart systemd-sysctl") docker.succeed("grep 1 /proc/sys/net/ipv4/conf/all/forwarding") docker.succeed("grep 1 /proc/sys/net/ipv4/conf/default/forwarding") </ins> ''; })