jiebi/CodeConvo huggingface dataset:
Code change:
sha256 = "0wmw823ildwm9rcfyk22pvzg100yhps3y9hfjlrpspfd1hhkbp0d"; <del> extraPatches = [ ]; </del> <ins> extraPatches = [ reapplyPathSanitizerPatch ]; </ins> }; }

Related discussion:
text: Describe the bug When booting with ZFS legacy mountpoints like this: the boot fails as described in this post: To Reproduce I guess this is difficult if not anyone is having this issue with legacy mountpoints, but it seems that in the linked discourse post, I'm not the only one with this issue. But I've tested it just on this commit: where it fails, and on this (just one commit before): And there everything works. Expected behavior Mounting of legacy ZFS mountpoints succeeds while booting. Notify maintainers <!-- Metadata Please run and paste the result. Maintainer information: --
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Can you check if this is fixed by ?
I tried with this overlay: Not sure if that's the way to do it, but it didn't work.
it should probably be
Thanks I tried that, and it didn't work. Not sure how to confirm the patch got applied properly though.
if you have the log output, you will have something like:
Guys, just to report, I'm in the latest zen with ZFS 2.0.1-1 with encryption, unstable channel and I'm not having any problems.
I've just found time to test this, thanks for the research. The patch did indeed fix the issue for me! (I've checked the log output for the application of the patch). For the sake of completeness the overlay I've applied (needed a slightly different sha256 sum for me):
Could you make a PR adding the patch to zfs?
Code change:
<ins> { config, lib, pkgs, ... }: let cfg = config.programs.darling; in { options = { programs.darling = { enable = lib.mkEnableOption (lib.mdDoc "Darling, a Darwin/macOS compatibility layer for Linux"); package = lib.mkPackageOptionMD pkgs "darling" {}; }; }; config = lib.mkIf cfg.enable { security.wrappers.darling = { source = lib.getExe cfg.package; owner = "root"; group = "root"; setuid = true; }; }; } </ins>

Related discussion:
text: Darling is a compatibility layer for running macOS apps on Linux (think Wine for macOS). I think it would be interesting to work on with macOS support. They have reverse engineered some headers that Apple doesn't release publicly so having them in "libdarling" could be useful.
We already have this part:
Just heard of Darling. I would be delighted if it could be used for running builds on NixOS!
It seem to be packaged by but only for macOS. If i understand the project correctly, that makes no sense. We want it on linux, to run macOS apps. Also, the package has no version. That's probably because they havn't tagged a version yet. So this is pre-alpha state software. could you update the package to the commit the "stable" AUR package uses and add a version as described here: ? Then we can close this issue.
It looks like the project has started using tagged versions:
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 . 3. Ask on the on .
I'd still be very interested in seeing this , especially with the hope of future cross-compilation support
This would even make it possible to package Mac binaries for Linux!
I'm interested in this so that I can test cross compiled binaries when running tests.
I marked this as stale due to inactivity. &rarr;
Not stale!!
darling-dmg is just part of . To be exact, it is included as a submodule in the source tree of darling. The darling build will come with kernel modules. It would need someone with kernel-packaging experience to pack it into Nixpkgs. Build instructions in the Darling Docs:
I marked this as stale due to inactivity.
Code change:
<ins> { config, lib, pkgs, ... }: let cfg = config.programs.darling; in { options = { programs.darling = { enable = lib.mkEnableOption (lib.mdDoc "Darling, a Darwin/macOS compatibility layer for Linux"); package = lib.mkPackageOptionMD pkgs "darling" {}; }; }; config = lib.mkIf cfg.enable { security.wrappers.darling = { source = lib.getExe cfg.package; owner = "root"; group = "root"; setuid = true; }; }; } </ins>

Related discussion:
text: &rarr;
I'd still like to see this, though largely for much the same reason Andrew mentions at this point -- I've started working with zig and being able to test cross-compiled macos binaries would be brilliant.
I have got most of a Darling build file running, but I have found an interesting issue. Wever I build I get the following error: From this cmake file: As far as I can tell, the command is a special MacOS thing, and I unfortunately do not understand CMake well enough to fix it...
Well, turns out the issue is that Darling relies on git-submodules, and it looks like this must be built against the Git repo directly, not against the released tarball...
What would therefore be a derivation?
What do you mean It's just a with .
I tried to re-package the prebuilt deb from darling GitHub releases. Here is the nix code darling- Save these 2 snippets as and darling-, then run . With 2 problems: needs setuid/setgid perms, while nix-build would fail if dpkg-deb -x executed directly. I use fakeroot to ignore this problem. always fails. I am not a darling expert, have no idea.
Ah, fantastic, thanks! Looking forward to having this in nixpkgs anyway, but let's see how we go there.
It could be named when entering Nixpkgs.
Good suggestion. I've edited those two scripts.
I got as far as finding out that darlingserver doesn't start with that script because it expects /usr/bin, so updating my to a version, the next issue was that darlingserver was trying to mount overlayfs on "lowerdir=/usr/libexec/darling,up" (may be incomplete, this is strace output) which did not exist.
After a bit of tinkering I got Darling to build from source. I opened with more info. Please give it a try!
It seems that they now use instead of the kernel module. This would make packaging easier.
What's the purpose of ? If it is only the sandbox part of Darling, a new name like would bring less confusion. Update: Opened PR to do the renaming.
Code change:
{ stdenv, fetchurl, makeWrapper, pkgconfig, nss, nspr, libqb <del> , dbus, librdmacm, libibverbs, libstatgrab, net_snmp </del> <ins> , dbus, rdma-core, libstatgrab, net_snmp </ins> , enableDbus ? false , enableInfiniBandRdma ? false , enableMonitoring ? false

Related discussion:
text: The packages and are outdated () and have been replaced by the package (). To update a derivation just replace those two packages by as a build input. The following packages depend on and/or : [x] openmpi (fixed in ) [x] (does not find librdmacm in the configure phase when compiled against rdma-core) [x] (infiniband support seems to be defunct. configure does not check for IB libs and it is not linked against any of the required libs, libibverbs or librdmacm) [x] (RDMA support was removed from )
Code change:
ThomasMader = "Thomas Mader <thomas.mader@gmail.com>"; thoughtpolice = "Austin Seipp <aseipp@pobox.com>"; timbertson = "Tim Cuthbertson <tim@gfxmonk.net>"; <ins> timokau = "Timo Kaufmann <timokau@zoho.com>"; </ins> titanous = "Jonathan Rudenberg <jonathan@titanous.com>"; tnias = "Philipp Bartsch <phil@grmr.de>"; tohl = "Tomas Hlavaty <tom@logand.com>";

Related discussion:
text: Since Sage is huge and complicated, I figured I would make this issue to collaboratively track progress and share branches. One big issue is that Sage 7 , instead they use some with scant documentation . has the correct SHA256 for Sage 7.6 and updates a patch file. It currently fails when Sage tries to build . Some nice things to do for the future: ) cc:
thanks for picking this up
Me myself being a miserable loser who has failed to update Sage in the past, I hope you succeed… My attempt hit the following wall. It is unbearably slow to let Sage build everything, but when I had convinced it to use the system versions of majority of dependencies it began to complain cryptically about their interaction in some case.
Can you elaborate? Do you have a branch that has that work? Also, to be clear: I probably don't have the skills or time to upgrade Sage by myself, I was hoping that if we shared our knowledge and de-duplicated efforts we might be able to get closer together
I think it was 6-dot-something; it required a metric ton of adding options to the packages in NixPkgs (I have pushed that all to master long ago), and the Sage tricks are most likely too version-specific. It was long enough ago that I have since abandoned and lost the changes.
In case anybody in here is still waiting for this: I got sage to compile and run. I'm currently trying to minimize the dependencies and check that everything is working correctly (there is one doctest failure, but it was mentioned multiple times in the mailing list and apperas to be harmles -- just a timeout). I'll probably make a PR in the next couple of days.
Code change:
ThomasMader = "Thomas Mader <thomas.mader@gmail.com>"; thoughtpolice = "Austin Seipp <aseipp@pobox.com>"; timbertson = "Tim Cuthbertson <tim@gfxmonk.net>"; <ins> timokau = "Timo Kaufmann <timokau@zoho.com>"; </ins> titanous = "Jonathan Rudenberg <jonathan@titanous.com>"; tnias = "Philipp Bartsch <phil@grmr.de>"; tohl = "Tomas Hlavaty <tom@logand.com>";

Related discussion:
text: Sage needs texlive-core-2014, which is deprecated. Run with modern nixpkgs (i.e. from git) System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:
Code change:
}; url_preview_url_blacklist = mkOption { type = types.listOf types.str; <del> default = [ "127.0.0.0/8" "10.0.0.0/8" "172.16.0.0/12" "192.168.0.0/16" "100.64.0.0/10" "169.254.0.0/16" ]; </del> <ins> default = []; </ins> description = '' Optional list of URL matches that the URL preview spider is denied from accessing.

Related discussion:
text: default value causes previews to fail. the usual homeserver config Do not configure (so that the default value is used) Post URL into a preview enabled room Find similar error in synapse log: The option defaults to . Were those values intended as default for the option? Excerpt from a working configuration: /cc (as you discussed the security implications in )
Seems like a good bet.
thanks for fixing this, I was just wondering about this earlier today:
Code change:
patches = [ (substituteAll { src = ./libpq.patch; <del> libpq = "${postgresql.lib}/lib/libpq.so"; </del> <ins> libpq = "${postgresql.lib}/lib/libpq${stdenv.hostPlatform.extensions.sharedLibrary}"; </ins> }) ];

Related discussion:
text: Steps to reproduce the behavior: -env -iA (full output here: ) Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
The error is not in pgcli but in psycopg which tries to import a .so which does not work under darwin.
Code change:
<del> { lib, stdenv, fetchurl, unzip, blas, lapack, gfortran }: </del> <ins> { lib , stdenv , fetchFromGitHub , pkg-config , blas , lapack , gfortran , enableAMPL ? stdenv.isLinux, libamplsolver }: </ins> assert (!blas.isILP64) && (!lapack.isILP64); stdenv.mkDerivation rec { pname = "ipopt"; <del> version = "3.12.13"; </del> <ins> version = "3.14.5"; </ins> <del> src = fetchurl { url = "https://www.coin-or.org/download/source/Ipopt/Ipopt-${version}.zip"; sha256 = "0kzf05aypx8q5mr3sciclk926ans0yi2d2chjdxxgpi3sza609dx"; </del> <ins> src = fetchFromGitHub { owner = "coin-or"; repo = "Ipopt"; rev = "releases/${version}"; sha256 = "sha256-eqOacZGuuGAjWMs2H6RntQ+WJmGTi+EqydHUQXEpY54="; </ins> }; CXXDEFS = [ "-DHAVE_RAND" "-DHAVE_CSTRING" "-DHAVE_CSTDIO" ]; configureFlags = [ <del> "--with-blas-lib=-lblas" "--with-lapack-lib=-llapack" </del> <ins> "--with-asl-cflags=-I${libamplsolver}/include" "--with-asl-lflags=-lamplsolver" </ins> ]; <del> nativeBuildInputs = [ unzip gfortran ]; buildInputs = [ blas lapack ]; </del> <ins> nativeBuildInputs = [ pkg-config gfortran ]; buildInputs = [ blas lapack ] ++ lib.optionals enableAMPL [ libamplsolver ]; </ins> enableParallelBuilding = true;

Related discussion:
text: A clear and concise description of what the bug is. The package doesn't include a folder. I am looking for a version of which includes the executable. Are we building the package incorrectly such that it doesn't include a binary? Any and all help/advice is much appreciated :bow: Steps to reproduce the behavior: output - notice there is no folder A clear and concise description of what you expected to happen. I want the executable. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- might know something about this? :man_shrugging:
was the binary there before On a quick note: I have never used , so I am not familiar with the package. It seems that the package also needs an update:
It appears that the binary requires AMPL, a commercial package, which is not packaged in nixpkgs. See: https://coin-
ah, I understand. Thank you.
Code change:
"-DENABLE_TESTING=${enableIf doCheck}" "-DDISABLE_META_INTEGRATION_TESTS=ON" "-DTRAVIS_DISABLE_META_CPP=ON" <del> "-DPythonModular=${enableIf pythonSupport}" </del> <ins> "-DINTERFACE_PYTHON=${enableIf pythonSupport}" </ins> "-DOpenCV=${enableIf opencvSupport}" "-DUSE_SVMLIGHT=${enableIf withSvmLight}" ];

Related discussion:
text: Using Shogun as a for another CMake-based project fails because the dependent project cannot properly find the shogun library (via its installed cmake files). Steps to reproduce the behavior: to build a derivation based on shogun files are wrong Everything builds correctly I am trying to build the following derivation However I get an error at the build generation step: This indicates that shogun CMake files are not in the right place and/or are pointing towards the wrong paths.
I fixed the issue with shogun. When installing the configuration files, CMake calculates the prefix to the installed library based on the output directory, instead of the default , and I missed it when I split the derivation into multiple outputs. I wonder why it's not a more widespread issue, only a few derivations patch it. But that derivation still doesn't build: This is in macOS, though. Maybe it works on Linux.
Thanks, is the fix committed yet? The other error is unrelated and I can fix it.
I'm working on the PR.
Code change:
stdenv.mkDerivation rec { pname = "clojure"; <del> version = "1.10.3.855"; </del> <ins> version = "1.10.3.933"; </ins> src = fetchurl { # https://clojure.org/releases/tools url = "https://download.clojure.org/install/clojure-tools-${version}.tar.gz"; <del> sha256 = "sha256-y2PuOBRq5kZlTpPV8NwkWhspQKlNxwjl+k/Drwixk4Q="; </del> <ins> sha256 = "sha256-xsm0/HNWr8a/7iLQVC9TbUkASWvw/EI3bD0dMDhLZXA="; </ins> }; nativeBuildInputs = [

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 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: clojure <!-- 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: 1.10.3.855 desired version: 1.10.3.933 <!-- 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.
Opened a PR:
Code change:
sourceRoot = "pyside-setup-everywhere-src-${version}/sources/${pname}"; <del> patches = [ ./fix-include-qt-headers.patch ]; </del> <ins> patches = [ ./fix-include-qt-headers.patch # Remove this patch when updating to 6.8.0 (fetchpatch { name = "backwards-compatibility-with-6.6.x.patch"; url = "https://code.qt.io/cgit/pyside/pyside-setup.git/patch/?id=4f9a20e3635f4f0957e0774588b1d9156e88a572"; hash = "sha256-B2jhLWopgaSF/rUXMZFPZArDUNojlBgn7kdVyQull+I="; stripLen = 2; }) ]; </ins> nativeBuildInputs = [ cmake

Related discussion:
text: Steps to reproduce the behavior: cutter Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Any news on this?
Code change:
<ins> commit 1b0d9bcc5f5cd78b0bb1357d6a11da5d616ad26f Author: Wout Mertens <Wout.Mertens@gmail.com> Date:   Thu Jun 11 18:08:13 2020 +0200 fix segfault when using ECDSA keys. Author: Marc Deslauriers <marc.deslauriers@canonical.com> Bug-Ubuntu: https://bugs.launchpad.net/bugs/1869512 diff --git a/ssh-ecdsa.c b/ssh-ecdsa.c index 5b13b30..5bf29cc 100644 --- a/ssh-ecdsa.c +++ b/ssh-ecdsa.c @@ -46,7 +46,7 @@ ssh_ecdsa_sign(const Key *key, u_char **sigp, u_int *lenp, u_int len, dlen; Buffer b, bb; #if OPENSSL_VERSION_NUMBER >= 0x10100005L -	BIGNUM *r, *s; +	BIGNUM *r = NULL, *s = NULL; #endif if (key == NULL || key->type != KEY_ECDSA || key->ecdsa == NULL) { @@ -137,20 +137,27 @@ ssh_ecdsa_verify(const Key *key, const u_char *signature, u_int signaturelen, /* parse signature */ if ((sig = ECDSA_SIG_new()) == NULL) -        pamsshagentauth_fatal("ssh_ecdsa_verify: DSA_SIG_new failed"); +        pamsshagentauth_fatal("ssh_ecdsa_verify: ECDSA_SIG_new failed"); pamsshagentauth_buffer_init(&b); pamsshagentauth_buffer_append(&b, sigblob, len); #if OPENSSL_VERSION_NUMBER < 0x10100005L if ((pamsshagentauth_buffer_get_bignum2_ret(&b, sig->r) == -1) || (pamsshagentauth_buffer_get_bignum2_ret(&b, sig->s) == -1)) +        pamsshagentauth_fatal("ssh_ecdsa_verify:" +            "pamsshagentauth_buffer_get_bignum2_ret failed"); #else -    DSA_SIG_get0(sig, &r, &s); +    if ((r = BN_new()) == NULL) +        pamsshagentauth_fatal("ssh_ecdsa_verify: BN_new failed"); +    if ((s = BN_new()) == NULL) +        pamsshagentauth_fatal("ssh_ecdsa_verify: BN_new failed"); if ((pamsshagentauth_buffer_get_bignum2_ret(&b, r) == -1) || (pamsshagentauth_buffer_get_bignum2_ret(&b, s) == -1)) -#endif pamsshagentauth_fatal("ssh_ecdsa_verify:" "pamsshagentauth_buffer_get_bignum2_ret failed"); +    if (ECDSA_SIG_set0(sig, r, s) != 1) +        pamsshagentauth_fatal("ssh_ecdsa_verify: ECDSA_SIG_set0 failed"); +#endif /* clean up */ memset(sigblob, 0, len); </ins>

Related discussion:
text: Describe the bug After upgrading to NixOS 20.03, sudo often (but not always) segfaults: From the logs: Disabling appears to have made this problem to away, so the problem may be in . Metadata NixOS 20.03..
Maybe the patch to use a not insecure openssl is the source of the issue for you
same issue here - the sourceforge repo is way old, there's a github mirror but not maintained either, and there's a fork of the mirror which includes fixes for openssl 1.1.1:
I marked this as stale due to inactivity. &rarr;
Hmm, kinda forgot about this
I missed the fact that the "supported" branch didn't actually include the patch to fix this.
Code change:
denonavr = callPackage ../development/python-modules/denonavr { }; <ins> dep-logic = callPackage ../development/python-modules/dep-logic { }; </ins> dependency-injector = callPackage ../development/python-modules/dependency-injector { }; deploykit = callPackage ../development/python-modules/deploykit { };

Related discussion:
text: Steps to reproduce the behavior: truststore Output of : Adding to solves this issue. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
, nodePackages, bash # Attributes inherit from specific versions <del> , version, src, meta, sourceRoot </del> <ins> , version, src, meta, sourceRoot, commandLineArgs </ins> , executableName, longName, shortName, pname, updateScript # sourceExecutableName is the name of the binary in the source archive, over # which we have no control

Related discussion:
text: For Chromium, there's a convenient way to define custom flags through . However, there doesn't seem to be a similar option for . I tried setting to "--touch-events", but touchscreen scrolling is not enabled when starting VSCode from desktop launcher, while running in console works as expected. Steps to reproduce the behavior: to "--touch-events" VSCode from desktop launcher on the editor area through touchscreen The editor should scroll as I drag. system: host os: multi-user?: sandbox: version: channels(yes): channels(root): nixpkgs:
Code change:
gotypist = callPackage ../games/gotypist { }; <del> heroic-unwrapped = callPackage ../games/heroic { }; </del> <ins> heroic-unwrapped = callPackage ../games/heroic { # Match the version used by the upstream package. electron = electron_24; }; </ins> heroic = callPackage ../games/heroic/fhsenv.nix { };

Related discussion:
text: Upon launching,  white screens without any visible errors. or the app white screen It works without white screening Since runs fine when using its pre-built AppImage, I don't suspect that there is any issue with my hardware, drivers, or software. After testing, I have found out that the issue exists on specifically. It works fine on KDE. (Note: I haven't tried on similar environments like Sway) Running produces the following output upon exiting : Hello,
I am thinking of adding a package so that any user facing this or similar issues can use pre-built binaries as a instant solution than waiting for existing nix expressions to be fixed. Please guide me if you guys think this should/can be done. (The NixOS manual doesn't provide much help with wrappers around AppImages)
Could you please run in a terminal (in the environment where the issue occurs) and paste the output in a comment, in a . I also have a few questions, you get those same errors when you run from the terminal? this X11 KDE, or Wayland KDE? is your GPU, and which drivers are you using? I don't think we should do this. If a user wants to run pre-built binaries from upstream, there are straightforward ways to do so. Since Heroic ships an AppImage, you can use .
I've already tried running heroic from a terminal and weirdly, there's absolutely no error that shows up. Which makes me think it's a purely front-end error given heroic uses electron. , I do. KDE . My driver setup is contained in Yeah, that makes sense. But how do I make sure it's always installed on my system? Do I have to run every single time I need to launch?
Update: I have tested this in Sway as well and the app does white screen with no errors in the terminal.
Try running Heroic from the branch I just pushed (command below) to see if it resolves the issue. I've changed the Electron version the package uses to match that of the upstream package, as there seems to be a regression in the latest version of Electron.
Just tested this. I don't get the white screen anymore!!
This happens for me now, trying the nix shell now.
That fixed it, thanks!