jiebi/CodeConvo huggingface dataset:
Code change:
During configure, ’s configuration script checks for certain features of the command, to quote the source: The latter two are not available on macOS, but nevertheless get enabled (I suppose is in when configuring?). Things we can do: with on darwin. haven’t really looked into how this build system works, but maybe we can pass configure flags to explicitly disable these features no matter what on darwin? it away.
For searchability, a typical error would be:
FTR I’m not quire sure where to apply any of the fixes, probably in . (/cc

Related discussion:
text: ''; }); <ins> # On Darwin, git-annex mis-detects options to `cp`, so we wrap the binary to # ensure it uses Nixpkgs' coreutils. git-annex = with pkgs; if (!stdenv.isLinux) then let path = stdenv.lib.makeBinPath [ coreutils ]; in overrideCabal (addBuildTool super.git-annex makeWrapper) (_drv: { postFixup = '' wrapProgram $out/bin/git-annex  --prefix PATH : "${path}" ''; }) else super.git-annex; </ins> # The test suite has undeclared dependencies on git. githash = dontCheck super.githash;
Code change:
(this is a qt specific test): Loc: [t-(458)] PASS : TofuInfoTest::cleanupTestCase() Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 1047ms This seems to affect master too, but for some reason it's been built successfully once. The aarch64 build started failing when updating qt5 from 5.11 to 5.12 making it the likely root cause: Edit: the cause was expired testing keys: cc maintainer cc as you've been active in keeping plasma/kde up to date lately. ping staging next:
Did you found ? Sounds very similar and should be fixed...
No didn't find that, but yeah, that sure looks exactly like the same issue. I'm guessing the qt issue were never actually fixed: Blame on the test gives no change at least:
And applying the suggested patch does fix the test: diff +++ gpgme-1.10.0/lang/qt/tests/t- -455,7 +455,7 private Q_SLOTS: QVERIFY(result.numSignatures() == 1); auto sig = result.signatures()[0]; QVERIFY(sig.validity() == Signature::Marginal); QVERIFY(sig.validity() == Signature::Marginal sig.validity() == Signature::Unknown); auto stats = ().userID(0).tofuInfo(); QVERIFY(!stats.isNull());
So, what are we want to do? Do you maybe want to comment on the upstream issue?
Hmm, strange, I'm getting the same failure on master (using ), forcing single core does not fix the problem though, so probably not a race condition. I've reported the failure as you suggested:
The cause is most likely qt 5.11 to 5.12 upgrade, as the aarch64 build started failing the test then:
So the keys used in this test expired on 2019-01-06, which explains why we suddenly saw this without any apparent reason. :
Thanks for fixing this and sorry for my late reply... (Edit: And of course also thanks

Related discussion:
text: { stdenv, fetchurl, libgpgerror, gnupg, pkgconfig, glib, pth, libassuan , file, which, ncurses <del> , autoreconfHook </del> <ins> , autoreconfHook, fetchpatch </ins> , git , texinfo , qtbase ? null
Code change:
(this is a qt specific test): Loc: [t-(458)] PASS : TofuInfoTest::cleanupTestCase() Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 1047ms This seems to affect master too, but for some reason it's been built successfully once. The aarch64 build started failing when updating qt5 from 5.11 to 5.12 making it the likely root cause: Edit: the cause was expired testing keys: cc maintainer cc as you've been active in keeping plasma/kde up to date lately. ping staging next:
Did you found ? Sounds very similar and should be fixed...
No didn't find that, but yeah, that sure looks exactly like the same issue. I'm guessing the qt issue were never actually fixed: Blame on the test gives no change at least:
And applying the suggested patch does fix the test: diff +++ gpgme-1.10.0/lang/qt/tests/t- -455,7 +455,7 private Q_SLOTS: QVERIFY(result.numSignatures() == 1); auto sig = result.signatures()[0]; QVERIFY(sig.validity() == Signature::Marginal); QVERIFY(sig.validity() == Signature::Marginal sig.validity() == Signature::Unknown); auto stats = ().userID(0).tofuInfo(); QVERIFY(!stats.isNull());
So, what are we want to do? Do you maybe want to comment on the upstream issue?
Hmm, strange, I'm getting the same failure on master (using ), forcing single core does not fix the problem though, so probably not a race condition. I've reported the failure as you suggested:
The cause is most likely qt 5.11 to 5.12 upgrade, as the aarch64 build started failing the test then:
So the keys used in this test expired on 2019-01-06, which explains why we suddenly saw this without any apparent reason. :
Thanks for fixing this and sorry for my late reply... (Edit: And of course also thanks

Related discussion:
text: nativeBuildInputs = [ file pkgconfig gnupg autoreconfHook git texinfo ] ++ lib.optionals pythonSupport [ python swig2 which ncurses ]; <ins> patches = [ (fetchpatch { name = "fix-key-expiry.patch"; url = "https://files.gnupg.net/file/data/fehgbjmataj5tc2pnfhj/PHID-FILE-aqck6l4elhw53tjanrie/file"; sha256 = "1h80m045gy7r0g7dzzlfpql6p065x88p274ij9jnf7d4lwwgrf1a"; }) ]; </ins> postPatch ='' substituteInPlace ./configure --replace /usr/bin/file ${file}/bin/file '';
Code change:
An update of zip-archive package from 0.3.3 to 0.4 in is causing a runtime error in elm compiler (). It would be good to set the elm's dependency on zip-archive to version < 0.4 until this gets fixed.
probably best to patch it
I think fixes it, will try to find more time to test tomorrow morning.
Shoot, I forgot all about this -- I did confirm that commit fixes it, I will clean up and open a PR soon.

Related discussion:
text: elmPackages = (import ./packages/elm-srcs.nix); versionsDat = ./versions.dat; }; <ins> patches = [ (fetchpatch { url = "https://github.com/elm/compiler/pull/1886/commits/39d86a735e28da514be185d4c3256142c37c2a8a.patch"; sha256 = "0nni5qx1523rjz1ja42z6z9pijxvi3fgbw1dhq5qi11mh1nb9ay7"; }) ]; </ins> buildTools = drv.buildTools or [] ++ [ makeWrapper ]; jailbreak = true; postInstall = ''
Code change:
should be enables horizontal scrolling
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .

Related discussion:
text: default = true; description = lib.mdDoc '' <del> Disables horizontal scrolling. When disabled, this driver will discard any horizontal scroll events from libinput. Note that this does not disable horizontal scrolling, it merely discards the horizontal axis from any scroll events. </del> <ins> Enables or disables horizontal scrolling. When disabled, this driver will discard any horizontal scroll events from libinput. This does not disable horizontal scroll events from libinput; it merely discards the horizontal axis from any scroll events. </ins> ''; };
Code change:
I tried to enable syncing Unix passwords to Samba via PAM using the option. However, I see a bunch of errors in the logs because the library PAM is looking for, , doesn't exist. Use the following config: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(USER): channels(root): nixpkgs:
Same issue here. The folder it was searching for () only contains on my system. Additionally, querying for presents no results.
Just experienced exactly same issue on 19.03. Is samba broken in this release?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
It's still relevant now. I noticed this issue in my system logs as well. Samba is not broken, they've just deprecated this feature. See and . Here's a PR for us:

Related discussion:
text: "password sufficient ${pkgs.sssd}/lib/security/pam_sss.so use_authtok"} ${optionalString config.krb5.enable "password sufficient ${pam_krb5}/lib/security/pam_krb5.so use_first_pass"} <del> ${optionalString config.services.samba.syncPasswordsByPam "password optional ${pkgs.samba}/lib/security/pam_smbpass.so nullok use_authtok try_first_pass"} </del> ${optionalString cfg.enableGnomeKeyring "password optional ${pkgs.gnome3.gnome-keyring}/lib/security/pam_gnome_keyring.so use_authtok"}
Code change:
I tried to enable syncing Unix passwords to Samba via PAM using the option. However, I see a bunch of errors in the logs because the library PAM is looking for, , doesn't exist. Use the following config: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(USER): channels(root): nixpkgs:
Same issue here. The folder it was searching for () only contains on my system. Additionally, querying for presents no results.
Just experienced exactly same issue on 19.03. Is samba broken in this release?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
It's still relevant now. I noticed this issue in my system logs as well. Samba is not broken, they've just deprecated this feature. See and . Here's a PR for us:

Related discussion:
text: [global] security = ${cfg.securityType} passwd program = /run/wrappers/bin/passwd %u <del> pam password change = ${smbToString cfg.syncPasswordsByPam} </del> invalid users = ${smbToString cfg.invalidUsers} ${cfg.extraConfig}
Code change:
I tried to enable syncing Unix passwords to Samba via PAM using the option. However, I see a bunch of errors in the logs because the library PAM is looking for, , doesn't exist. Use the following config: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(USER): channels(root): nixpkgs:
Same issue here. The folder it was searching for () only contains on my system. Additionally, querying for presents no results.
Just experienced exactly same issue on 19.03. Is samba broken in this release?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
It's still relevant now. I noticed this issue in my system logs as well. Samba is not broken, they've just deprecated this feature. See and . Here's a PR for us:

Related discussion:
text: { imports = [ (mkRemovedOptionModule [ "services" "samba" "defaultShare" ] "") <ins> (mkRemovedOptionModule [ "services" "samba" "syncPasswordsByPam" ] "This option has been removed by upstream, see https://bugzilla.samba.org/show_bug.cgi?id=10669#c10") </ins> ]; ###### interface
Code change:
I tried to enable syncing Unix passwords to Samba via PAM using the option. However, I see a bunch of errors in the logs because the library PAM is looking for, , doesn't exist. Use the following config: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(USER): channels(root): nixpkgs:
Same issue here. The folder it was searching for () only contains on my system. Additionally, querying for presents no results.
Just experienced exactly same issue on 19.03. Is samba broken in this release?
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
It's still relevant now. I noticed this issue in my system logs as well. Samba is not broken, they've just deprecated this feature. See and . Here's a PR for us:

Related discussion:
text: ''; }; <del> syncPasswordsByPam = mkOption { type = types.bool; default = false; description = '' Enabling this will add a line directly after pam_unix.so. Whenever a password is changed the samba password will be updated as well. However, you still have to add the samba password once, using smbpasswd -a user. If you don't want to maintain an extra password database, you still can send plain text passwords which is not secure. ''; }; </del> invalidUsers = mkOption { type = types.listOf types.str; default = [ "root" ];
Code change:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.

Related discussion:
text: udev = config.systemd.package; <del> modulesTree = config.system.modulesTree; </del> <ins> kernel-name = config.boot.kernelPackages.kernel.name or "kernel"; modulesTree = config.system.modulesTree.override { name = kernel-name + "-modules"; }; </ins> firmware = config.hardware.firmware;
Code change:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.

Related discussion:
text: # The closure of the init script of boot stage 1 is what we put in # the initial RAM disk. initialRamdisk = pkgs.makeInitrd { <ins> name = "initrd-${kernel-name}"; </ins> inherit (config.boot.initrd) compressor prepend; contents =
Code change:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.

Related discussion:
text: # `contents = {object = ...; symlink = /init;}' is a typical # argument. <del> { stdenv, perl, cpio, contents, compressor, prepend, ubootTools </del> <ins> { stdenv, perl, cpio, contents, ubootTools , name ? "initrd" , compressor ? "gzip -9n" , prepend ? [] </ins> }: stdenv.mkDerivation rec { <del> name = "initrd"; </del> <ins> inherit name; </ins> builder = ./make-initrd.sh; makeUInitrd = stdenv.hostPlatform.platform.kernelTarget == "uImage";
Code change:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.

Related discussion:
text: <del> { stdenv, kmod, modules, buildEnv }: </del> <ins> { stdenv, kmod, modules, buildEnv, name ? "kernel-modules" }: </ins> buildEnv { <del> name = "kernel-modules"; </del> <ins> inherit name; </ins> paths = modules;
Code change:
always has the same , and the same filename inside. Build NixOS with , look into I think it would be sometimes more convenient if the kernel version would be clear for each (which is actually initramfs). I think it would be better to literally include the as a suffix to .
This sounds like a sane idea to me.

Related discussion:
text: makeAutostartItem = callPackage ../build-support/make-startupitem { }; <del> makeInitrd = { contents, compressor ? "gzip -9n", prepend ? [ ] }: callPackage ../build-support/kernel/make-initrd.nix { inherit contents compressor prepend; }; </del> <ins> makeInitrd = callPackage ../build-support/kernel/make-initrd.nix; # Args intentionally left out </ins> makeWrapper = makeSetupHook { deps = [ dieHook ]; substitutions = { shell = pkgs.runtimeShell; }; } ../build-support/setup-hooks/make-wrapper.sh;
Code change:
I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc

Related discussion:
text: # /usr/bin/env gets special treatment so that ".../bin/env python" is # rewritten to /nix/store/<hash>/bin/python.  Interpreters that are # already in the store are left untouched. <ins> # A script file must be marked as executable, otherwise it will not be # considered. </ins> fixupOutputHooks+=(patchShebangsAuto) <del> # Run patch shebangs on a directory. # patchShebangs [--build | --host] directory </del> <ins> # Run patch shebangs on a directory or file. # Can take multiple paths as arguments. # patchShebangs [--build | --host] PATH... </ins> # Flags: # --build : Lookup commands available at build-time
Code change:
I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc

Related discussion:
text: shift fi <del> local dir="$1" header "patching script interpreter paths in $dir" </del> <ins> echo "patching script interpreter paths in $@" </ins> local f local oldPath local newPath
Code change:
I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc

Related discussion:
text: local oldInterpreterLine local newInterpreterLine <del> [ -e "$dir" ] || return 0 </del> <ins> if [ $# -eq 0 ]; then echo "No arguments supplied to patchShebangs" >0 return 0 fi </ins> local f while IFS= read -r -d $'0' f; do
Code change:
I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc

Related discussion:
text: # - options: something starting with a '-' # - environment variables: foo=bar if $(echo "$arg0" | grep -q -- "^-.*|.*=.*"); then <del> echo "$f: unsupported interpreter directive "$oldInterpreterLine" (set dontPatchShebangs=1 and handle shebang patching yourself)" </del> <ins> echo "$f: unsupported interpreter directive "$oldInterpreterLine" (set dontPatchShebangs=1 and handle shebang patching yourself)" >0 </ins> exit 1 fi
Code change:
I have been burned by this several times; and I am not alone: When calling with multiple arguments, we should either patch all of them or print an error. Ignoring arguments silently should be a crime. cc

Related discussion:
text: rm "$timestamp" fi fi <del> done < <(find "$dir" -type f -perm -0100 -print0) </del> <ins> done < <(find "$@" -type f -perm -0100 -print0) </ins> stopNest }
Code change:
building some cross-compiled packages and inspecting their run-time closures: will show that depends on (on master ). this is because the package isn't spliced correctly: The cross compiled packages depend on the folder, but this path also contains x86 binaries in it! (like ). This causes a bunch of other run-time x86 dependencies to be packaged with the cross-compiled binaries. pointed me here: , which is possibly broken. Trying to move the ARM libs into the output caused a cyclic dependency between the lib output and the normal output :( so I'm stuck & posting this issue. build a cross-compiled binary with a cross , notice that it has x86 binaries in it's run-time closure (assuming the build system is x86): system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:

Related discussion:
text: // lib.optionalAttrs (stdenv.hostPlatform != stdenv.buildPlatform) { preInstall = null; # clobber the native hook <del> dontStrip = true; separateDebugInfo = false; # this is currently broken for crossDrv </del> # To avoid a dependency on the build system 'bash'. preFixup = '' rm -f $bin/bin/{ldd,tzselect,catchsegv,xtrace}
Code change:
fails with the vdirsyncer version from nixos-unstable. it works if I install vdirsyncer with pip. Output of :
Which do you get via ? Is it the old 0.16 branch or the new 0.17 one (which was mostly rewritten in rust)? We have the latest git version of 0.17 in nixpkgs. Unfortunately, so it might be some time before this bug is fixed.
outputs this:
Same problem here. Was there any reason to go for an alpha release except for the issue referenced in ? If not, a downgrade to 0.16.7 should be fine, since the original bug is still open and probably won't be fixed for a while without anyone maintaining vdirsyncer.
There are , so I'd rather not downgrade. I'd be happy with a package for the 0.16 branch though.
That'd be great! I haven't looked into packaging yet, so it would take some time if I tried. Would you mind helping out?
I just opened a PR. It’s my first time contributing to , so I hope it’s up to snuff.

Related discussion:
text: github = "lo1tuma"; name = "Mathias Schreck"; }; <ins> loewenheim = { email = "loewenheim@mailbox.org"; github = "loewenheim"; name = "Sebastian Zivota"; }; </ins> lopsided98 = { email = "benwolsieffer@gmail.com"; github = "lopsided98";