jiebi/CodeConvo huggingface dataset:
Code change:
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. &rarr;
Still an issue
I marked this as stale due to inactivity. &rarr;

Related discussion:
text: , installShellFiles , git , unzip <del> , dmd_bin ? "${callPackage ./bootstrap.nix { }}/bin" </del> <ins> , dmdBootstrap ? callPackage ./bootstrap.nix { } , dmd_bin ? "${dmdBootstrap}/bin" </ins> }: let
Code change:
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. &rarr;
Still an issue
I marked this as stale due to inactivity. &rarr;

Related discussion:
text: 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/";
Code change:
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!

Related discussion:
text: <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>
Code change:
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!

Related discussion:
text: 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 { };
Code change:
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. &rarr;

Related discussion:
text: 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> ''; };
Code change:
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. &rarr;

Related discussion:
text: group = cfg.group; uid = config.ids.uids.caddy; home = cfg.dataDir; <del> createHome = true; </del> }; };
Code change:
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. &rarr;

Related discussion:
text: 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> }; }
Code change:
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. &rarr;

Related discussion:
text: <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 = ''
Code change:
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:

Related discussion:
text: 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"; };
Code change:
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. &rarr;
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)

Related discussion:
text: }; }; <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 ];
Code change:
, 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!

Related discussion:
text: 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> }; }
Code change:
, 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!

Related discussion:
text: license = licenses.asl20; platforms = platforms.linux ++ platforms.darwin; maintainers = [ maintainers.bjornfor ]; <ins> knownVulnerabilities = [ "CVE-2020-13949" ]; </ins> }; }
Code change:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also:

Related discussion:
text: 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> }; }
Code change:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also:

Related discussion:
text: license = licenses.asl20; platforms = platforms.linux ++ platforms.darwin; maintainers = [ maintainers.bjornfor ]; <ins> knownVulnerabilities = [ "CVE-2020-13949" ]; </ins> }; }
Code change:
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:

Related discussion:
text: <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>
Code change:
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:

Related discussion:
text: flamegraph = callPackage ../development/tools/flamegraph { }; <ins> flawfinder = callPackage ../development/tools/flawfinder { }; </ins> flips = callPackage ../tools/compression/flips { }; fmbt = callPackage ../development/tools/fmbt {
Code change:
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

Related discussion:
text: }; checkInputs = [ python3.pkgs.pytest ]; <ins> nativeBuildInputs = with python3.pkgs; [ setuptools-scm ]; </ins> propagatedBuildInputs = with python3.pkgs; [ Babel
Code change:
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

Related discussion:
text: ++ 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;
Code change:
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

Related discussion:
text: homepage = "https://www.lesbonscomptes.com/recoll/"; license = licenses.gpl2; platforms = platforms.unix; <del> maintainers = [ maintainers.jcumming ]; </del> <ins> maintainers = with maintainers; [ jcumming kiyengar ]; </ins> }; }
Code change:
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

Related discussion:
text: 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 { };
Code change:
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.

Related discussion:
text: 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;