jiebi/CodeConvo huggingface dataset:
Code change:
<ins> { autoPatchelfHook, fetchurl, lib, stdenv }: stdenv.mkDerivation rec { pname = "julia-bin"; version = "1.8.0"; src = { x86_64-linux = fetchurl { url = "https://julialang-s3.julialang.org/bin/linux/x64/${lib.versions.majorMinor version}/julia-${version}-linux-x86_64.tar.gz"; sha256 = "sha256-6A1zLMt/eeAA15jLi2Vtw2QatZUW1uTlLhZ2UBeJKgA="; }; }.${stdenv.hostPlatform.system} or (throw "Unsupported system: ${stdenv.hostPlatform.system}"); postPatch = '' # Julia fails to pick up our Certification Authority root certificates, but # it provides its own so we can simply disable the test. Patching in the # dynamic path to ours require us to rebuild the Julia system image. substituteInPlace share/julia/stdlib/v${lib.versions.majorMinor version}/NetworkOptions/test/runtests.jl  --replace '@test ca_roots_path() != bundled_ca_roots()'  '@test_skip ca_roots_path() != bundled_ca_roots()' ''; nativeBuildInputs = [ autoPatchelfHook ]; installPhase = '' runHook preInstall cp -r . $out runHook postInstall ''; # Breaks backtraces, etc. dontStrip = true; doInstallCheck = true; preInstallCheck = '' export JULIA_TEST_USE_MULTIPLE_WORKERS=true # Some tests require read/write access to $HOME. export HOME="$TMPDIR" ''; installCheckPhase = '' runHook preInstallCheck # Command lifted from `test/Makefile`. $out/bin/julia  --check-bounds=yes  --startup-file=no  --depwarn=error  $out/share/julia/test/runtests.jl runHook postInstallCheck ''; meta = { description = "High-level, high-performance, dynamic language for technical computing"; homepage = "https://julialang.org"; # Bundled and linked with various GPL code, although Julia itself is MIT. license = lib.licenses.gpl2Plus; maintainers = with lib.maintainers; [ ninjin raskin ]; platforms = [ "x86_64-linux" ]; mainProgram = "julia"; }; } </ins>

Related discussion:
text: <!-- 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 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: <!-- The current version can be found easily with the same process as 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: 1.7.3 desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
I started preparing the update in . Cc:
Code change:
{ stdenv, python3, fetchFromGitHub, fetchpatch }: with python3.pkgs; buildPythonApplication rec { <del> version = "3.8"; </del> <ins> version = "4.1"; </ins> pname = "buku"; src = fetchFromGitHub { owner = "jarun"; repo = "buku"; rev = "v${version}"; <del> sha256 = "0gv26c4rr1akcaiff1nrwil03sv7d58mfxr86pgsw6nwld67ns0r"; </del> <ins> sha256 = "166l1fmpqn4hys4l0ssc4yd590mmav1w62vm9l5ijhjhmlnrzfax"; </ins> }; checkInputs = [

Related discussion:
text: tests pass, while tests fail with: Official Hydra sees the same thing: with their Travis setup. (That is a build of a recent commit, but I still see the same failures after pointing at a checkout of ) Does anyone have any ideas? With nixpkgs master,
See scrapinghub/dateparser, scrapinghub/dateparser and scrapinghub/dateparser.
As long as this problem remains, the best thing to do is using for affected application. Switching to should be done in commits that don't change anything else and that reference this issue in their commit message so that they can easily be reverted. Simply skipping the tests does not make much sense since these are real incompatibilities.
Code change:
<ins> { lib , stdenv , fetchFromGitHub , pkg-config , fftw , zita-convolver , fftwFloat , libsndfile , ffmpeg , alsa-lib , libao , libmad , ladspaH , libtool , libpulseaudio }: stdenv.mkDerivation rec { pname = "dsp"; version = "1.8"; src = fetchFromGitHub { owner = "bmc0"; repo = "dsp"; rev = "v${version}"; sha256 = "sha256-LTgjpzAGi3oL8l5NcJj1ortKFd3vWDfXHr8YyedAxEE="; }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ fftw zita-convolver fftwFloat libsndfile ffmpeg alsa-lib libao libmad ladspaH libtool libpulseaudio ]; meta = with lib; { homepage = "https://github.com/bmc0/dsp"; description = "An audio processing program with an interactive mode"; license = licenses.isc; maintainers = with maintainers; [ aaronjheng ]; platforms = platforms.linux ++ platforms.darwin; }; } </ins>

Related discussion:
text: Project description is an audio processing program with an interactive mode. Also has a LADSPA frontend. Metadata homepage URL: source URL: license: isc platforms: linux
Code change:
, buildPythonPackage , fetchPypi , fetchpatch <ins> , stdenv </ins> , sphinx , numpydoc , pytest

Related discussion:
text: Describe the bug fails on Darwin. To Reproduce Steps to reproduce the behavior: Expected behavior Package builds Additional context Error log: <details<summaryError log</summary</detailsMetadata Please run and paste the result. host os: multi-user?: sandbox: version: channels(yl): nixpkgs: Maintainer information: Possibly related to
On the master branch, I removed the derivation from the nix store with and I built it without substitutes; failed with the same message. This is not caused by , but help me discover it due to the update of the requests python package.
maintainer:
I don't have a way to test on joblib for darwin so this is why I didn't have input on this PR. Is there an easy way to test nixpkgs on darwin? Hackintosh via kvm?
There is that works with some tweaking but I wouldn't describe it as easy. Another option is to ask @ GrahamcOfBorg to do the builds on the PR if there are not too many iterations to do.
Code change:
nixops = super.nixops.overridePythonAttrs ( old: { <ins> postPatch = '' substituteInPlace nixops/args.py --subst-var version ''; </ins> meta = old.meta // { homepage = https://github.com/NixOS/nixops; description = "NixOS cloud provisioning and deployment tool";

Related discussion:
text: The nixopsUnstable version is not set correctly. It should show the version. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Code change:
optionalString config.security.pam.enableEcryptfs '' password optional ${pkgs.ecryptfs}/lib/security/pam_ecryptfs.so '' + <ins> optionalString config.security.pam.enableFscrypt '' password optional ${pkgs.fscrypt-experimental}/lib/security/pam_fscrypt.so '' + </ins> optionalString cfg.pamMount '' password optional ${pkgs.pam_mount}/lib/security/pam_mount.so '' +

Related discussion:
text: I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. &rarr;
Code change:
${cfg.extraConfig} ''; qemuConfigFile = pkgs.writeText "qemu.conf" '' <ins> ${optionalString cfg.qemuOvmf '' nvram = ["${pkgs.OVMF}/FV/OVMF_CODE.fd:${pkgs.OVMF}/FV/OVMF_VARS.fd"] ''} </ins> ${cfg.qemuVerbatimConfig} '';

Related discussion:
text: In , I introduced support in libvirtd for UEFI VM creation. rightfully remarked that this brings closure-size up too much. Looking into OVMF shows that only 1MB out of the 114MB install size is needed to enable said UEFI VM creation. I think that we should look into splitting out OVMF_(CODE|VARS) from the rest package.
Code change:
chown ${bindUser} /var/run/named ''; <del> script = "${pkgs.bind.bin}/sbin/named -u ${bindUser} ${optionalString cfg.ipv4Only "-4"} -c ${cfg.configFile} -f"; </del> <ins> script = "${pkgs.bind.out}/sbin/named -u ${bindUser} ${optionalString cfg.ipv4Only "-4"} -c ${cfg.configFile} -f"; </ins> unitConfig.Documentation = "man:named(8)"; }; };

Related discussion:
text: The symlinking between the multiple outputs of seems to prevent it from installing. I was looking to install it to have the dig command available. - System: 17.03pre94050. (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "17.03pre94050."
11.4 still doesn't contain :-( How could we have that as default in 16.09? I consider it quite an important feature for + multiple outputs. would you be against porting that PR to 1.11.5 and making that default in 16.09 and master?
+1 for a 1.11.5 Nix release in general :)
Since this seems to be an issue for multiple packages, I am raising the severity on here.
Looks like the same kind of issue as So +1 for Nix 1.11.5 on NixOS 16.09, if that's what it takes to fix this.
ping again about nix-1.11.5 (my comment above).
Code change:
, gnome , gtksourceview4 , gjs <del> , webkitgtk_4_1 </del> <ins> , libsoup , webkitgtk </ins> , icu , wrapGAppsHook , gst_all_1

Related discussion:
text: Describe the bug When I try to preview videos like .mp4 or webm in Nautilus using Sushi, it says "Your GStreamer installation is missing a plug-in". To Reproduce Steps to reproduce the behavior: NixOS with Gnome3 desktop space on a video file in Nautilus Additional context It's possible that there's some configuration in my homedir that makes it break, since I have the same homedir that I had under other Linux installs, not sure how to find it however. outputs Notify maintainers maybe? Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(wmertens): channels(root): nixpkgs: Maintainer information:
Would need to add here, I think.
that makes sense - it seems like I would like the bad and the ugly too. How about a nixpkgs configuration setting that decides which plugin sets to load, and having plugins-base include them? That should make it backwards-compatible.
Most of them depend on base so that would be a dependency cycle. Also we would need to move the wrappers into a separate derivation or we would have to rebuild everything. Alternately, you can set environment variable (I believe some NixOS module does that). Not a fan but it should work provided some ABI break does not sneak in.
I marked this as stale due to inactivity. &rarr;
Still a problem
I marked this as stale due to inactivity. &rarr;
if sushi is not a dependent of any package then why would we have to rebuild everything? What do you mean by everything? Perhaps until a separate wrapper derivation is composed we can add a configuration option to the nixos module that would add these gstreamer to it if needed. Also, doesn't work at all for me nowadays, I think since Gnome 41.
I was replying to Wout’s question above regarding a general solution pulling extra plug-ins into gst-plugins-base. For now, I would be fine with adding everything unconditionally to sushi as mentioned in I must have forgotten to test it during the update when I removed libmusicbrainz but forgot to add libsoup: Could you try
Code change:
}; security.pam.enableEcryptfs = mkEnableOption (lib.mdDoc "eCryptfs PAM module (mounting ecryptfs home directory on login)"); <ins> security.pam.enableFscrypt = mkEnableOption (lib.mdDoc '' Enables fscrypt to automatically unlock directories with the user's login password. This also enables a service at security.pam.services.fscrypt which is used by fscrypt to verify the user's password when setting up a new protector. If you use something other than pam_unix to verify user passwords, please remember to adjust this PAM service. ''); </ins> users.motd = mkOption { default = null;

Related discussion:
text: I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. &rarr;
Code change:
linkFarm "zig-packages" [ { <del> name = "122014eeb4600a059bdcfe1c864862f17e6d5e4237e3bb7d6818f2a5583f6f4eb843"; </del> <ins> name = "1220687c8c47a48ba285d26a05600f8700d37fc637e223ced3aa8324f3650bf52242"; </ins> path = fetchzip { <del> url = "https://codeberg.org/ifreund/zig-pixman/archive/v0.1.0.tar.gz"; hash = "sha256-Atfkiyt9v+GWry3xA2Y0Iv6AvwbZ+EHfHLmX0AUEz6Y="; </del> <ins> url = "https://codeberg.org/ifreund/zig-wayland/archive/v0.2.0.tar.gz"; hash = "sha256-dvit+yvc0MnipqWjxJdfIsA6fJaJZOaIpx4w4woCxbE="; </ins> }; } { <del> name = "1220714d1cc39c3abb1d9c22a0b838d847ead099cb7d9931821490483f30c022e827"; </del> <ins> name = "12209db20ce873af176138b76632931def33a10539387cba745db72933c43d274d56"; </ins> path = fetchzip { <del> url = "https://codeberg.org/ifreund/zig-wlroots/archive/v0.17.0.tar.gz"; hash = "sha256-C1D2dBn65Z9PmDacpeYbdX574fcOyYi/BJVDUMibkPA="; </del> <ins> url = "https://codeberg.org/ifreund/zig-pixman/archive/v0.2.0.tar.gz"; hash = "sha256-zcfZEMnipWDPuptl9UN0PoaJDjy2EHc7Wwi4GQq3hkY="; </ins> }; } { <del> name = "1220840390382c88caf9b0887f6cebbba3a7d05960b8b2ee6d80567b2950b71e5017"; </del> <ins> name = "1220c65ab884c236cc950b564c70f6cd04046d86485ee76e0cde886cef7438021b4f"; </ins> path = fetchzip { <del> url = "https://codeberg.org/ifreund/zig-xkbcommon/archive/v0.1.0.tar.gz"; hash = "sha256-xilmsDGWlkfpTiGff+/nb76jx87ANdr4zqYy6rKOBMg="; </del> <ins> url = "https://codeberg.org/ifreund/zig-wlroots/archive/v0.17.1.tar.gz"; hash = "sha256-rVI/tJD3cx8b+nGTG5u08/RYoI179oDY7AY0riTntA0="; </ins> }; } { <del> name = "1220b0f8f822c1625af7aae4cb3ab2c4ec1a4c0e99ef32867b2a8d88bb070b3e7f6d"; </del> <ins> name = "1220c90b2228d65fd8427a837d31b0add83e9fade1dcfa539bb56fd06f1f8461605f"; </ins> path = fetchzip { <del> url = "https://codeberg.org/ifreund/zig-wayland/archive/v0.1.0.tar.gz"; hash = "sha256-VLEx8nRgmJZWgLNBRqrR7bZEkW0m5HTRv984HKwoIfA="; </del> <ins> url = "https://codeberg.org/ifreund/zig-xkbcommon/archive/v0.2.0.tar.gz"; hash = "sha256-T+EZiStBfmxFUjaX05WhYkFJ8tRok/UQtpc9QY9NxZk="; </ins> }; } ]

Related discussion:
text: Package name: river Latest released version: 0.3.3 <!-- Search your package here: --- Current version on the unstable channel: 0.3.2 Current version on the stable/release channel: 0.3.2 <!-- 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! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
3 is only a zig 0.13 compatibility release. It’s blocked by
has been merged, this is not blocked anymore.
Code change:
patchPhase = ''patchShebangs . '' + stdenv.lib.optionalString stdenv.isDarwin '' sed -i 's/#ifndef __MAC_10_11/#if 1/' ./libavcodec/audiotoolboxdec.c <ins> '' + stdenv.lib.optionalString (frei0r != null) '' substituteInPlace libavfilter/vf_frei0r.c  --replace /usr/local/lib/frei0r-1 ${frei0r}/lib/frei0r-1 substituteInPlace doc/filters.texi  --replace /usr/local/lib/frei0r-1 ${frei0r}/lib/frei0r-1 </ins> ''; configureFlags = [

Related discussion:
text: When using filters, look for them in and co. Instead it should look for it in for example. Setting the environment variable can work around that issue: . But it would be nice to have it work out of the box. Result: System: 17.03.1556. (Gorilla)
Code change:
inherit pname version; inherit src; <del> npmDepsHash = "sha256-+pr9fWg/9kxkYMmthtqhjgF6MOomSQxVCO5V8tHHRdE="; </del> <ins> npmDepsHash = "sha256-7oh5bl5APAvzb/TxHMUP/saRWLwuP9xqGvn7/RDhFk8="; </ins> npmFlags = [ "--legacy-peer-deps" ]; makeCacheWritable = true;

Related discussion:
text: Package name: feishin Latest released version: 0.7.1 <!-- Search your package here: --- Current version on the unstable channel: 0.6.1 Current version on the stable/release channel: 0.5.1 <!-- 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! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for reporting this, just noticed I hadn't subscribed to release notifications. Shouldn't miss any from now on :) Fixed by (awaiting review).
Code change:
qtdeclarative = [ ./qtdeclarative.patch ]; qtscript = [ ./qtscript.patch ]; qtserialport = [ ./qtserialport.patch ]; <del> qtwebengine = [ ] </del> <ins> qtwebengine = [ # Fix build with bison-3.7: https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?id=1a53f599 (fetchpatch { name = "qtwebengine-bison-3.7-build.patch"; url = "https://code.qt.io/cgit/qt/qtwebengine-chromium.git/patch/?id=1a53f599"; sha256 = "1nqpyn5fq37q7i9nasag6i14lnz0d7sld5ikqhlm8qwq9d7gbmjy"; stripLen = 1; extraPrefix = "src/3rdparty/"; }) ] </ins> ++ optional stdenv.isDarwin ./qtwebengine-darwin-no-platform-check.patch; qtwebkit = [ (fetchpatch {

Related discussion:
text: Describe the bug qtwebengine fails just after successfully configuring with error message To Reproduce ` Expected behavior should compile Notify maintainers Metadata
Pull request works on my machine. Thx.
Code change:
, pango , pulseaudio , python3 <ins> , stdenv </ins> , util-linux , which , x264 , x265 , xauth <ins> , xdg-utils </ins> , xorg , xorgserver }:

Related discussion:
text: Xpra supports forwarding invocations from the server to the client. The Xpra client defaults to hardcoding as the command to invoke on the client, which does not exist in NixOS. This bug does not impact hosts other than NixOS. Steps to reproduce the behavior: somehow. The Xpra client should invoke the local . N/A. This could be fixed by setting the open command to just , but it might match the intent better to change it to something like perhaps. Presumably, the point of doing it this way is to avoid any other copies of that might appear on the , e.g. Xpra's own. I suppose we can't really rely on to exist: even if we could on NixOS, we can't on other Linux distributions running Nix, where might make more sense. It seems to me that the best compromise, then, is to hardcode a path to copy of and users can override this using the option if needed. The open command that Xpra uses is configurable on the client-side, but the default is set as a platform-specific variable. On Linux, it is set in . Because there are separate values for both Windows and Darwin hosts, patching the value to shouldn't ever break them (but of course it should still be a Linux-specific patch, otherwise it unnecessarily brings into the closure.) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

Related discussion:
text: Julia 1.5 is out, see: and we don't have it packaged. More over, see how defines our other Julias: Several issues: is pointing to a TLS version which is old IMO. Certainly there are breaking changes seen in , but since Nixpkgs is a somewhat rolling release distro, are we going to keep these older versions and default to them for ever? I've once tried to reach for the community to hear if there's a strict policy regarding such scenarios, but Anyway, I'd like to propose a change that will keep only the LTS version and the latest - currently 1.4, and perhaps make the attribute , point to the latest. Any thoughts from maintainers or users? cc
Also, now I noticed all of our Julias fail to build, e.g:
I agree. And the 1.5 release candidates are out, so this will become the latest version in the near future. Last time I looked, the package built the same deps for all versions, including 0.7. In versions 1.0 and later, there are actually fewer dependencies (e.g. arpack and fftw have been dropped), so the package should be cleaned up to not include these unnecessary libraries in the build. I also think the default version should be the latest version (i.e., unless somebody explicitly installs julia-1-lts, they should get the latest).
OK I'm glad I have your support. I'll let this issue stay open for a while and hopefully I'll be able to take care of this a month or so from now.
cc
Back when Julia tests were not so messed up, I think there was often 1 previous version. I guess with 1.3 needing overriding to no tests, it is fine to just have julia-1-lts and Julia 1.4 as julia once Julia 1.4 gets built fine with some tests.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Haven't had a lot of time to work on julia in nixpkgs, so just posting this as a FYI.