jiebi/CodeConvo huggingface dataset:
Change:
Describe the bug I installed john the ripper from the binary cache, and executing it fails with: I have a recent laptop (Thinkpad T480s) with i7-8550U CPUs, but apparently that's not good enough. It would be good to compile john with less demanding requirements for the benefit of most users, and maybe output a message how to compile it yourself on nix systems.
Yeah it looks like one of the builders has this feature so the configure script requires it: It looks like we need to pass the flag.
cc maintainer
backported to 19.09 in .

Discussion:
export AS=$CC export LD=$CC ''; <del> configureFlags = [ "--disable-native-macro" ]; </del> <ins> configureFlags = [ "--disable-native-tests" "--with-systemwide" ]; </ins> buildInputs = [ openssl nss nspr kerberos gmp zlib libpcap re2 ]; nativeBuildInputs = [ gcc python3Packages.wrapPython perl makeWrapper ];

# gcc: error: memdbg.o: No such file or directory enableParallelBuilding = false; <del> NIX_CFLAGS_COMPILE = [ "-DJOHN_SYSTEMWIDE=1" ]; </del> postInstall = '' mkdir -p "$out/bin" "$out/etc/john" "$out/share/john" "$out/share/doc/john" "$out/share/john/rules" find -L ../run -mindepth 1 -maxdepth 1 -type f -executable 

description = "John the Ripper password cracker"; license = licenses.gpl2; homepage = https://github.com/magnumripper/JohnTheRipper/; <del> maintainers = with maintainers; [ offline ]; platforms = [ "x86_64-linux" "x86_64-darwin"]; </del> <ins> maintainers = with maintainers; [ offline matthewbauer ]; platforms = platforms.unix; </ins> }; }
Change:
Describe the bug Using commit . See build output . Gimp builds fine.
I knew I was forgetting something. This is likely fallout from I was partially fixing it in : but a more proper fix is necessary.

Discussion:
"--without-webkit" # old version is required "--with-bug-report-url=https://github.com/NixOS/nixpkgs/issues/new" "--with-icc-directory=/run/current-system/sw/share/color/icc" <ins> # fix libdir in pc files (${exec_prefix} needs to be passed verbatim) "--libdir=${exec_prefix}/lib" </ins> ]; # on Darwin,
Change:
On 19.09, when you on NixOS with default settings and your user being part of unix group , you get a prompt whether you want to get admin capabilities via your user or the user. This is somewhat inconvenient, because you always have to choose the user by clicking on it (or pressing a number key in the terminal); on other systems like Ubuntu, it somehow figures out that these two are identical and prompts immediately for the password. In we have both as the default. Setting it to only generates only 1 prompt. What is the first one good for, should we just remove it from the default, given that adding users to the is the default way of "making them admins"? Or do we somehow want to depart from the unix group approach of making people admins?
These are the patches used in ubuntu and also debian The default upstream for is So seemingly ubuntu and many other distro's aren't doing what we are doing. We use for probably a specific reason at some point in time.
It appears to have been this way for a long time My recommendation is we just use the default way it is in polkit. As far as I can tell, is how it's done in NixOS.
Right, most notably which does saying Seems reasonable to me as well

Discussion:
The fourStore and fourStoreEndpoint modules have been removed. </para> </listitem> <ins> <listitem> <para> Polkit no longer has the user of uid 0 (root) as an admin identity. We now follow the upstream default of only having every member of the wheel group admin privileged. Before it was root and members of wheel. The positive outcome of this is pkexec GUI popups or terminal prompts will no longer require the user to choose between two essentially equivalent choices (whether to perform the action as themselves with wheel permissions, or as the root user). </para> </listitem> </ins> </itemizedlist> </section>

security.polkit.adminIdentities = mkOption { type = types.listOf types.str; <del> default = [ "unix-user:0" "unix-group:wheel" ]; </del> <ins> default = [ "unix-group:wheel" ]; </ins> example = [ "unix-user:alice" "unix-group:admin" ]; description = '' Specifies which users are considered “administrators”, for those actions that require the user to authenticate as an administrator (i.e. have an <literal>auth_admin</literal> <del> value).  By default, this is the <literal>root</literal> user and all users in the <literal>wheel</literal> group. </del> <ins> value).  By default, this is all users in the <literal>wheel</literal> group. </ins> ''; };
Change:
On master, reptyr is hanging:
This is fixed in reptyr master, bisected to:

Discussion:
<del> { stdenv, lib, fetchFromGitHub, python2 }: </del> <ins> { stdenv, lib, fetchFromGitHub, fetchpatch, python2 }: </ins> stdenv.mkDerivation rec { version = "0.7.0";

sha256 = "1hnijfz1ab34j2h2cxc3f43rmbclyihgn9x9wxa7jqqgb2xm71hj"; }; <ins> patches = [ # Fix tests hanging (fetchpatch { url = "https://github.com/nelhage/reptyr/commit/bca3070ac0f3888b5d37ee162505be81b3b496ff.patch"; sha256 = "0w6rpv9k4a80q0ijzdq5hlpr37ncr284piqjv5agy8diniwlilab"; }) ]; </ins> makeFlags = [ "PREFIX=" "DESTDIR=$(out)" ]; checkInputs = [ (python2.withPackages (p: [ p.pexpect ])) ];
Change:
As described here it would be useful to add an option in to add a systemd entry which forces GPU's to always be online even in headless systems. Here is what the extracted systemd service would look like (taken from )

Discussion:
enabled = nvidia_x11 != null; cfg = config.hardware.nvidia; pCfg = cfg.prime; syncCfg = pCfg.sync; offloadCfg = pCfg.offload; primeEnabled = syncCfg.enable || offloadCfg.enable; <ins> nvidiaPersistencedEnabled =  cfg.nvidiaPersistenced; </ins> in {

<option>hardware.nvidia.prime.intelBusId</option>). ''; }; <ins> hardware.nvidia.nvidiaPersistenced = mkOption { default = false; type = types.bool; description = '' Update for NVIDA GPU headless mode, i.e. nvidia-persistenced. It ensures all GPUs stay awake even during headless mode. ''; }; </ins> }; config = mkIf enabled {

++ optional (nvidia_x11.persistenced != null && config.virtualisation.docker.enableNvidia) "L+ /run/nvidia-docker/extras/bin/nvidia-persistenced - - - - ${nvidia_x11.persistenced}/origBin/nvidia-persistenced"; <ins> systemd.services."nvidia-persistenced" = mkIf nvidiaPersistencedEnabled { description = "NVIDIA Persistence Daemon"; wantedBy = [ "multi-user.target" ]; serviceConfig = { Type = "forking"; Restart = "always"; PIDFile = "/var/run/nvidia-persistenced/nvidia-persistenced.pid"; ExecStart = "${nvidia_x11.persistenced}/bin/nvidia-persistenced --verbose"; ExecStopPost = "${pkgs.coreutils}/bin/rm -rf /var/run/nvidia-persistenced"; }; }; </ins> boot.extraModulePackages = [ nvidia_x11.bin ]; # nvidia-uvm is required by CUDA applications.
Change:
Describe the bug postPatch hook is failed for , so not substituted by and CVE-2005-2471, mentioned in the , not treated. To Reproduce Steps to reproduce the behavior: Output: Expected behavior postPatch hook successfully executed at the end of the patch phase. Additional context Seems should contain instead of and instead of ? Metadata Please run and paste the result.
It appears that the original "-dSAFER" is already enough to mitigate the CVE-2005-2471. But since Arch still uses "-dPARANOIDSAFER", we might as well use that too.
Thanks, fixed. I think the substitution warnings should be fatal by default, but that's a more general issue (and a "breaking" change).

Discussion:
postPatch = /* CVE-2005-2471, from Arch */ '' substituteInPlace converter/other/pstopnm.c  <del> --replace '"-DSAFER"' '"-DPARANOIDSAFER"' </del> <ins> --replace '"-dSAFER"' '"-dPARANOIDSAFER"' </ins> ''; buildInputs =
Change:
Request for a new nix package for openmesh : library for polygonal meshes Thank you. OpenMesh is a generic and efficient data structure for representing and manipulating polygonal meshes. OpenMesh is developed at the Computer Graphics Group, RWTH Aachen. It was funded by the German Ministry for Research and Education ( BMBF). It was designed with the following goals in mind: Flexibility : provide a basis for many different algorithms without the need for adaptation. Efficiency : maximize time efficiency while keeping memory usage as low as possible. Ease of use : wrap complex internal structure in an easy-to-use interface.
I think it would help if you described why you need the library packaged. Do you plan to include any software that uses the library into the distribution?
Yes it will be feasible later. At the moment I would like to develop and launch continuous integration with Nix. I have 7/8 libraries and I need this last one under Nix to start. Note that this library is very stable, recognized in the domain of meshes, simpler than CGAL, small, without dependency... It is also on Mac with HomeBrew for example.
I don't want to maintain it, but this derivation will get you up off the ground:
Thanks a lot, I will look that maybe after summer and maybe I will propose to be the maintainer of this package, we will see ! Thanks
I marked this as stale due to inactivity. &rarr;
Have you tried to package this?
No time for the moment. But I will look that when I can... or or
Modified from version to fit the URL for versions 10.0: Hi I saw your comment about the PR. If you have time now, that would be great. If not, I'd be happy to help and create the PR.
Hi No time sorry, so you can do that. Thanks !

Discussion:
<ins> { lib, stdenv, fetchFromGitLab, cmake, }: stdenv.mkDerivation (finalAttrs: { pname = "openmesh"; version = "11.0.0"; src = fetchFromGitLab { domain = "gitlab.vci.rwth-aachen.de:9000"; owner = "OpenMesh"; repo = "OpenMesh"; rev = "OpenMesh-${lib.versions.majorMinor finalAttrs.version}"; fetchSubmodules = true; sha256 = "sha256-1FmAieCaskKaaAWjgEXr/CWpFxrhB2Rca1sXpxLrQHw="; }; nativeBuildInputs = [ cmake ]; meta = with lib; { homepage = "https://www.graphics.rwth-aachen.de/software/openmesh/"; description = "Generic and efficient polygon mesh data structure"; maintainers = with maintainers; [ yzx9 ]; platforms = platforms.all; license = licenses.bsd3; }; }) </ins>
Change:
I have the following in my : And yet, despite setting , I still get the following error: I'm positive that my overrides are taking place, and that this isn't user error.
This is a bug in Nix/Nixpkgs: is too strict. See also
I filed to fix this. Did GitHub notify anybody here?
The first attempt from had to be reverted ().
Fixed by .
unfortunately, this change had the undesired side-effect of re-enabling the builds of all kinds of broken packages on Hydra, so now I get hundreds of evaluation errors where there used to be none, i.e.: How am I supposed to remedy that issue?
I'm a little confused by the fact/statement that there used to be none, but I think we can get rid of all, as there's now a lot of flexibility in handling the errors.
Note that this is the jobset -- not . That jobset always had zero evaluation errors until the behavior changed. I suppose I can fix most of them by changing the generator to set at the same time as . This used to be implicit before ...
I noticed but I didn't know you managed to clear all of them in haskell packages. I'll try to get rid of all (incl. trunk), as I expect that to be relatively easy now, but I can't promise it will be during this weekend already.

Discussion:
else true; in <del> assert licenseAllowed attrs; </del> lib.addPassthru (derivation ( (removeAttrs attrs ["meta" "passthru" "crossAttrs" "pos"

computedPropagatedImpureHostDeps = lib.unique (lib.concatMap (input: input.__propagatedImpureHostDeps or []) (propagatedBuildInputs ++ propagatedNativeBuildInputs)); in { <del> builder = attrs.realBuilder or shell; </del> <ins> builder = assert licenseAllowed attrs; attrs.realBuilder or shell; </ins> args = attrs.args or ["-e" (attrs.builder or ./default-builder.sh)]; stdenv = result; system = result.system;
Change:
Project description docker-credential-helpers is a suite of programs to use native stores to keep Docker credentials safe. Metadata (same as source) source URL: license: mit platforms: unix, linux, darwin Please note that contains multiple programs: (Windows specific) These might want to be shipped as independent packages Some of them are platform specific while others like , should work on both darwin (), linux and BSDs as well.

Discussion:
<ins> { stdenv, buildGoPackage, fetchFromGitHub, pkg-config, libsecret }: buildGoPackage rec { pname = "docker-credential-helpers"; version = "0.6.3"; goPackagePath = "github.com/docker/docker-credential-helpers"; src = fetchFromGitHub { owner = "docker"; repo = pname; rev = "v${version}"; sha256 = "0xgmwjva3j1s0cqkbajbamj13bgzh5jkf2ir54m9a7w8gjnsh6dx"; }; nativeBuildInputs = stdenv.lib.optionals stdenv.isLinux [ pkg-config ]; buildInputs = stdenv.lib.optionals stdenv.isLinux [ libsecret ]; buildPhase = if stdenv.isDarwin then '' cd go/src/${goPackagePath} go build -ldflags -s -o bin/docker-credential-osxkeychain osxkeychain/cmd/main_darwin.go '' else '' cd go/src/${goPackagePath} go build -o bin/docker-credential-secretservice secretservice/cmd/main_linux.go go build -o bin/docker-credential-pass pass/cmd/main_linux.go ''; installPhase = if stdenv.isDarwin then '' install -Dm755 -t $bin/bin bin/docker-credential-osxkeychain '' else '' install -Dm755 -t $bin/bin bin/docker-credential-pass install -Dm755 -t $bin/bin bin/docker-credential-secretservice ''; meta = with stdenv.lib; { description = "Suite of programs to use native stores to keep Docker credentials safe"; homepage = "https://github.com/docker/docker-credential-helpers"; license = licenses.mit; maintainers = [ maintainers.marsam ]; platforms = platforms.linux ++ platforms.darwin; }; } </ins>

docker-credential-gcr = callPackage ../tools/admin/docker-credential-gcr { }; <ins> docker-credential-helpers = callPackage ../tools/admin/docker-credential-helpers { }; </ins> doodle = callPackage ../applications/search/doodle { }; dr14_tmeter = callPackage ../applications/audio/dr14_tmeter { };
Change:
Describe the bug Pango now requires harfbuzz to build built with coretext, which is fine because we have harfbuzzFull. However, pango's include path for it is just when it should be I'm not sure how to tell meson to use a different include path :/ To Reproduce on darwin: Expected behavior builds Maintainer information:
..... nice, not sure why i didn't think of that :(

Discussion:
cairomm = callPackage ../development/libraries/cairomm { }; <del> pango = callPackage ../development/libraries/pango { }; </del> <ins> pango = callPackage ../development/libraries/pango { harfbuzz = harfbuzz.override { withCoreText = stdenv.isDarwin; }; }; </ins> pangolin = callPackage ../development/libraries/pangolin { inherit (darwin.apple_sdk.frameworks) Carbon Cocoa;
Change:
Describe the bug Franz is pointing to an incorrect executable so launching it doesn't work. To Reproduce Steps to reproduce the behavior: franz franz via the file an error saying Expected behavior Franz launches as expected Additional context According to the nix package is designed to replace the which just however in the latest version of Franz it doesn't seem to be working Metadata Maintainer information:
cc

Discussion:
# provide desktop item and icon cp -r usr/share $out substituteInPlace $out/share/applications/franz.desktop  <del> --replace Exec="/opt/Franz/franz" Exec=franz </del> <ins> --replace /opt/Franz/franz franz </ins> ''; dontWrapGApps = true;
Change:
fails with the following error on macOS: To Reproduce Steps to reproduce the behavior: Expected behavior sqitch's version should be printed. Additional context seems to be the original sqitch main file, while exports in preparation of calling the original (perl) main file. However, still contains a shebang with all the library paths (each path is appended five times, but that's a different matter) as the environment variable, and when it's called, it fails with this error: Trial and error shows that limiting the shebang line to 512 character fixes the “exec format error” issue, and since there is no need to add all the paths (five times) to the shebang – since they are in the enviroment variable set by – they can be removed. This fixes the issue. Metadata Maintainer information:

Discussion:
<del> { name, stdenv, perl, makeWrapper, sqitchModule, databaseModule }: </del> <ins> { name, stdenv, perl, makeWrapper, sqitchModule, databaseModule, shortenPerlShebang }: </ins> stdenv.mkDerivation { name = "${name}-${sqitchModule.version}";

src = sqitchModule; dontBuild = true; <ins> nativeBuildInputs = stdenv.lib.optional stdenv.isDarwin shortenPerlShebang; </ins> installPhase = '' mkdir -p $out/bin for d in bin/sqitch etc lib share ; do

ln -s ${sqitchModule}/$d $out/$d fi done <ins> '' + stdenv.lib.optionalString stdenv.isDarwin '' shortenPerlShebang $out/bin/sqitch </ins> ''; dontStrip = true; postFixup = "wrapProgram $out/bin/sqitch --prefix PERL5LIB : $PERL5LIB";
Change:
Describe the bug The (File System Visualizer) package is currently broken. It fails to build, with the error output referencing automake macros that are unsupported or undefined. To Reproduce Steps to reproduce the behavior: that the build fails. Expected behavior I expected the package to be built successfully and installed in my user environment. Screenshots If applicable, add screenshots to help explain your problem. Additional context Here is the build output I saw. Metadata Please run and paste the result. Maintainer information:
cc
Thank you for the report! It seems like a breaking change in gettext. I will push a fix ~tomorrow~ done.

Discussion:
sha256 = "0n09jd7yqj18mx6zqbg7kab4idg5llr15g6avafj74fpg1h7iimj"; }; <ins> postPatch = '' # fix build with gettext 0.20 sed -i 's/AM_GNU_GETTEXT/AM_GNU_GETTEXT([external])/' configure.in ''; </ins> nativeBuildInputs = [ autoreconfHook libtool pkgconfig ]; buildInputs       = [ file gtk2 libGLU gtkglarea ];
Change:
I get this error when trying to use the kafka scripts from the package: $ /nix/store/12ndbm9by7ccsb77lsx4kc9566pk4y6l-apache-kafka-2.10-0.8.2.1/bin/kafka-server- /nix/store/yh8hdd378j1gaaq73gk88ca7gzf590vg-apache-kafka-2.10-0.8.2.1/config/server.properties mkdir: cannot create directory ‘/nix/store/12ndbm9by7ccsb77lsx4kc9566pk4y6l-apache-kafka-2.10-0.8.2.1/bin/../logs’: Read-only file system log4j:ERROR setFile(null,true) call failed. /nix/store/12ndbm9by7ccsb77lsx4kc9566pk4y6l-apache-kafka-2.10-0.8.2.1/bin/../logs/kafka- (No such file or directory) at (Native Method)
Looks like this was fixed in the referenced commit?
This should probably be closed since it appears to be fixed and isn't responding.
Agreed

Discussion:
# allow us the specify logging directory using env substituteInPlace $out/bin/kafka-run-class.sh  <del> --replace 'LOG_DIR=$base_dir/logs' 'LOG_DIR=$KAFKA_LOG_DIR' </del> <ins> --replace 'LOG_DIR="$base_dir/logs"' 'LOG_DIR="$KAFKA_LOG_DIR"' </ins> for p in $out/bin/*.sh; do wrapProgram $p
Change:
Using the latest packages from the unstable channel I am unable to enable the default virsh network. The error indicates an issue with the firewall backend, but I disabled the firewall systemwide through: = false; What am I missing here? system: host os: multi-user?: sandbox: version: channels(root): channels(tim): nixpkgs:
Have you looked into libvirtd logs for a better characterization of the issue ?
Yes but I could not find anything meaninful, but I'll continue trying to find something
I'm seeing this the 2019-12-19 04:34:37.251+0000: 4078: error : virFileReadAll:1431 : Failed to open file '/sys/class/net/virbr0-nic/operstate': No such file or directory 2019-12-19 04:34:37.251+0000: 4078: error : virNetDevGetLinkInfo:2460 : unable to read: /sys/class/net/virbr0-nic/operstate: No such file or directory Also, I noticed that ebtables was updated recently.
I'm facing the same issue. I have the nixos firewall enabled, and it complains it can't find ebtables. If I install it separately that error goes away but I still see the errors posted by above
I confirmed that reverting ebtables to 2.0.10-4 fixes this. Not sure what the next step is.
Idea: set EBTABLES_PATH=/sbin/ebtables-legacy in libvirt config.
When bumped from 2.0.10-4 to 2.0.11, the binary was renamed to , so the configure script fails to find it at build time.
Impure workaround for the desperate: add the package to , and symlink to . (I also tried from the package, which does not seem to work.)
Another workaround for less desperate: in your overlay.
I verified that providing an to the right binary in the derivation allows my VMs to work again. I tested in a overlay I maintain, from which a minimal (untested) extract to work around the issue until someone has time to come up with a more correct patch to submit upstream is:
I've confirmed that the overlay in works.
I also have the issue. This is actually a major issue, if libvirt does not work anymore.
Had the same issue with unstable. The overlay above fixed it. Do we just need a PR to staging-next that adds that environment variable to the build? I'll submit that PR if that is all that is necessary -- didn't see any submitted yet.

Discussion:
] ++ optionals stdenv.isLinux [ "QEMU_BRIDGE_HELPER=/run/wrappers/bin/qemu-bridge-helper" "QEMU_PR_HELPER=/run/libvirt/nix-helpers/qemu-pr-helper" <ins> "EBTABLES_PATH=${ebtables}/bin/ebtables-legacy" </ins> "--with-attr" "--with-apparmor" "--with-secdriver-apparmor"