jiebi/CodeConvo huggingface dataset:
Code change:
, libxml2 , elfutils , mpi <ins> , systemd </ins> , gtest , python3Packages <del> , gpuTargets ? [ "gfx900" "gfx906" "gfx908" "gfx90a" "gfx940" "gfx941" "gfx942" "gfx1030" "gfx1100" "gfx1101" "gfx1102" ] </del> <ins> , gpuTargets ? clr.gpuTargets </ins> }: <del> stdenv.mkDerivation (finalAttrs: { </del> <ins> let rocmtoolkit-merged = symlinkJoin { name = "rocmtoolkit-merged"; paths = [ rocm-core rocm-thunk rocm-device-libs roctracer rocdbgapi rocm-smi hsa-amd-aqlprofile-bin clr ]; postBuild = '' rm -rf $out/nix-support ''; }; in stdenv.mkDerivation (finalAttrs: { </ins> pname = "rocprofiler"; version = "5.7.1";

Related discussion:
text: When trying to use rocprofv2: This might have something to do with some predefined paths in Steps to reproduce the behavior: an executable with hipcc it with rocprofv2 <!-- 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.
I need to do some work with . need to make a patch that strips. I need to fix itself. I wonder if it's because I'm stripping out the test directories? Also yes, it looks like you're right. You can fix that by prepending too, so I'm not entirely sure it'll work. Try setting `. You may just be able to run it from that as well.
I don't think that removing hsa-amd-aqlprofile-bin is a good idea, because without it, it loses performance counters support. I think there should at least be a rocprof derivation with aqlprofile.
My bad, I forgot to add that the patch is optional.
Right. Could you tell me your test environment and the source of the hip executable (or just some stub) so I can replicate this? I've never actually used rocprofiler.
You can try this, it just prints 10 numbers, it can be compiled with hipcc without any flag. I am using a radeon rx6600m(gfx1032).
see
Code change:
{ lib , fetchFromGitHub <del> , llvmPackages_13 </del> <ins> , llvmPackages </ins> , makeBinaryWrapper , libiconv , MacOSX-SDK

Related discussion:
text: Steps to reproduce the behavior: odin If you run the resulting binary through you'll see this strange backtrace: I think it has to do with the version of the C++ standard library that is getting linked. Adding and to the and updating the file to explicitly link allows it to run without segfaulting. (But thats just a workaround I'm using). EDIT: During more testing with the built binary, it also doesn't use the correct linker, which can cause problems if you are linking with Objective-C code/frameworks (not sure if this is a problem with how Odin is packaged with nix, or if its a problem that the Odin devs need to solve). Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Note: Was fixed by
macOS Odin support is kinda scuffed anyway with any deviation from what's expected. do you have the code for your workaround somewhere? then i can see if i can patch it in
I'm using for my project. It doesn't have any switching based on OS, and my override probably isn't necessary either. Honestly, the is probably the only thing needed to stop the seg faulting.
updating to llvm17 is not a bad idea either
Code change:
{ lib, stdenv, file, fetchurl, makeWrapper, autoPatchelfHook, jsoncpp, libpulseaudio }: let <del> versionMajor = "8.4"; versionMinor = "2"; </del> <ins> versionMajor = "8.13"; versionMinor = "1"; </ins> versionBuild_x86_64 = "1"; versionBuild_i686 = "1"; in

Related discussion:
text: Steps to reproduce the behavior: nomachine-client Seems like nomachine changed their tar file. <!-- 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]:
It seems that NoMachine has removed the from their website and the link is now a redirect to the homepage. The new latest version is .
? this url works
Code change:
<ins> { pkgs, lib, config, ... }: with lib; let cfg = config.services.gotify; in { options = { services.gotify = { enable = mkEnableOption "Gotify webserver"; port = mkOption { type = types.port; description = '' Port the server listens to. ''; }; stateDirectoryName = mkOption { type = types.str; default = "gotify-server"; description = '' The name of the directory below <filename>/var/lib</filename> where gotify stores its runtime data. ''; }; }; }; config = mkIf cfg.enable { systemd.services.gotify-server = { wantedBy = [ "multi-user.target" ]; after = [ "network.target" ]; description = "Simple server for sending and receiving messages"; environment = { GOTIFY_SERVER_PORT = toString cfg.port; }; serviceConfig = { WorkingDirectory = "/var/lib/${cfg.stateDirectoryName}"; StateDirectory = cfg.stateDirectoryName; Restart = "always"; DynamicUser = "yes"; ExecStart = "${pkgs.gotify-server}/bin/server"; }; }; }; } </ins>

Related discussion:
text: Project description A simple server for sending and receiving messages in real-time per WebSocket. Includes a web UI, also has an Android client for receiving notifications and an optional CLI program (distributed separately) for sending notifications. Metadata homepage URL: source URL: license: MIT platforms: anything Go runs on
I started an attempt locally, however it failed due to some timeouts while fetching Go dependencies... will retry during this week :)
I think the main difficulty is the UI, which needs to be compiled with NPM. In essence, I think the build is three-staged: fetch UI dependencies, fetch Go dependencies, do the actual build.
You may want to take a look at .
Code change:
functionTo = elemType: mkOptionType { name = "functionTo"; <del> description = "function that evaluates to a(n) ${elemType.name}"; </del> <ins> description = "function that evaluates to a(n) ${elemType.description}"; </ins> check = isFunction; merge = loc: defs: fnArgs: (mergeDefinitions (loc ++ [ "[function body]" ]) elemType (map (fn: { inherit (fn) file; value = fn.value fnArgs; }) defs)).mergedValue;

Related discussion:
text: When using an option with , the type description references the nested type's name instead of its description. This can lead to type descriptions like "function that evaluates to a(n) functionTo". Nix expression to reproduce: Reproduction in NixOS: The Nix expr should print something like "function that evaluates to a(n) function that evaluates to a(n) string". The command should print a type description like "function that evaluates to a(n) list of packages".
Code change:
}; }; <ins> vue.vscode-typescript-vue-plugin = buildVscodeMarketplaceExtension { mktplcRef = { name = "vscode-typescript-vue-plugin"; publisher = "Vue"; version = "1.8.27"; hash = "sha256-ym1+WPKBcn4h9lqSFVehfiDoGUEviOSEVXVLhHcYvfc="; }; meta = { changelog = "https://marketplace.visualstudio.com/items/Vue.vscode-typescript-vue-plugin/changelog"; description = "Vue VSCode extension for TypeScript"; downloadPage = "https://marketplace.visualstudio.com/items?itemName=Vue.vscode-typescript-vue-plugin"; homepage = "https://github.com/vuejs/language-tools"; license = lib.licenses.mit; }; }; </ins> waderyan.gitblame = buildVscodeMarketplaceExtension { mktplcRef = { name = "gitblame";

Related discussion:
text: Project description A VSCode extension that integrates Vue features with TypeScript features Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
client.succeed( "curl --cacert /tmp/ca.crt https://c.example.test/ | grep -qF 'hello world'" ) <ins> with subtest("Can request certificate of nginx when startup is delayed"): webserver.succeed( "${switchToNewServer}" ) webserver.succeed( "/run/current-system/specialisation/slow-startup/bin/switch-to-configuration test" ) webserver.wait_for_unit("acme-finished-d.example.com.target") client.succeed("curl --cacert /tmp/ca.crt https://d.example.com/") </ins> ''; })

Related discussion:
text: I use enabled. I also have a web server service that specifies: Because my web server is a bit long to start, the timeout and its systemd unit fails. To Reproduce Use the following example module: Expected behavior The acme systemd units created by  should wait that nginx is started before starting. Metadata Maintainer information:
Should adding to what is already to  fix the issue?
Making a note that has the same code and presumably the same issue so any fix on should likely be ported to .
Thank you for the issue and reproducer. I'll have a closer look at this today
what exactly do you mean by "timeout" here by the way. could you provide some journal logs of this failure? I can try reproduce when I'm home, but maybe the logs are enough to understand what is going wrong
I mean "Timeout during connect (likely firewall problem)" in the logs below. Note that the hostname, email and domain have been redacted. Also notice the long time between and . nginx was not started when the Let's Encrypt tried to retrieve the challenge:
I'm scared that won't work. The lack of here is very deliberate pulls in (Through and ) to create fake certs, as nginx crashes hard when certificate paths aren't present. We want to start up before the acme challenge is initiated, as nginx is responsible for serving the director to complete it. If starts before nginx, it will always fail. It's all a bit mind-boggling and the dependencies are a bit complicated. I wish it was a bit more simpler too. However; isn't what we want here instead? We want to guarentee that is running before the certificate request is fired off. So adding a to might work? I'll see if that fixes it..
Absolutely, that is what I meant but I wrote it wrongly.
Should we go for the solution proposed?
Yep. I have a PR in the works on my machine. I'll try to get it out this week
Code change:
harmonia = callPackage ../tools/package-management/harmonia { }; <ins> hayagriva = callPackage ../tools/typesetting/hayagriva { }; </ins> hcl2json = callPackage ../applications/misc/hcl2json { }; hcxtools = callPackage ../tools/security/hcxtools { };

Related discussion:
text: Project description Convert bibtex file to yaml which typst needed. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit, apache platforms: unix, linux, darwin, ...
Code change:
''; }; }; <ins> # When nginx depends on a service that is slow to start up, requesting used to fail # certificates fail.  Reproducer for https://github.com/NixOS/nixpkgs/issues/81842 specialisation.slow-startup.configuration = { pkgs, config, nodes, lib, ...}: { systemd.services.my-slow-service = { wantedBy = [ "multi-user.target" "nginx.service" ]; before = [ "nginx.service" ]; preStart = "sleep 5"; script = "${pkgs.python3}/bin/python -m http.server"; }; systemd.targets."acme-finished-d.example.com" = { after = [ "acme-d.example.com.service" ]; wantedBy = [ "acme-d.example.com.service" ]; }; services.nginx.virtualHosts."d.example.com" = { forceSSL = true; enableACME = true; locations."/".proxyPass = "http://localhost:8000"; }; }; </ins> }; client = {nodes, lib, ...}: {

Related discussion:
text: I use enabled. I also have a web server service that specifies: Because my web server is a bit long to start, the timeout and its systemd unit fails. To Reproduce Use the following example module: Expected behavior The acme systemd units created by  should wait that nginx is started before starting. Metadata Maintainer information:
Should adding to what is already to  fix the issue?
Making a note that has the same code and presumably the same issue so any fix on should likely be ported to .
Thank you for the issue and reproducer. I'll have a closer look at this today
what exactly do you mean by "timeout" here by the way. could you provide some journal logs of this failure? I can try reproduce when I'm home, but maybe the logs are enough to understand what is going wrong
I mean "Timeout during connect (likely firewall problem)" in the logs below. Note that the hostname, email and domain have been redacted. Also notice the long time between and . nginx was not started when the Let's Encrypt tried to retrieve the challenge:
I'm scared that won't work. The lack of here is very deliberate pulls in (Through and ) to create fake certs, as nginx crashes hard when certificate paths aren't present. We want to start up before the acme challenge is initiated, as nginx is responsible for serving the director to complete it. If starts before nginx, it will always fail. It's all a bit mind-boggling and the dependencies are a bit complicated. I wish it was a bit more simpler too. However; isn't what we want here instead? We want to guarentee that is running before the certificate request is fired off. So adding a to might work? I'll see if that fixes it..
Absolutely, that is what I meant but I wrote it wrongly.
Should we go for the solution proposed?
Yep. I have a PR in the works on my machine. I'll try to get it out this week
Code change:
name = "RStudio-${version}"; buildInputs = [ cmake boost163 zlib openssl R qt5.full qt5.qtwebkit libuuid unzip ant jdk makeWrapper pandoc ]; <del> nativeBuildInputs = [ qt5.qmake ]; </del> src = fetchurl { url = "https://github.com/rstudio/rstudio/archive/v${version}.tar.gz";

Related discussion:
text: Building RStudio fails with the following error message (seems to be something to do with the fact that QMake got upgraded): Run . System: (NixOS: , Ubuntu/Fedora: , ...) . Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
Code change:
let # when bumping the version, check if imhex has gotten support for the capstone version in nixpkgs <del> version = "1.26.2"; </del> <ins> version = "1.27.1"; </ins> patterns_src = fetchFromGitHub { owner = "WerWolv"; repo = "ImHex-Patterns"; rev = "ImHex-v${version}"; <del> hash = "sha256-2+7bJzgwHfXcINM5oxwi3vEbUtq9gGJc/uxFOwT4RnM="; </del> <ins> hash = "sha256-7Aaj+W+zXjHO8A2gmWtp5Pa/i5Uk8lXzX2WHjPIPRZI="; </ins> }; in

Related discussion:
text: Package name: imhex Latest released version: 1.27.1 <!-- Search your package here: --- Current version on the unstable channel: 1.26.2 Current version on the stable/release channel: 1.19.3 <!-- 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.
Code change:
<del> { lib, stdenv, fetchurl, fetchpatch, autoreconfHook, pkg-config, doxygen, perl, pam, nspr, nss, openldap , db, cyrus_sasl, svrcore, icu, net-snmp, libkrb5, pcre, perlPackages, libevent, openssl, python3 </del> <ins> { stdenv , autoreconfHook , fetchFromGitHub , lib , bzip2 , cmocka , cracklib , cyrus_sasl , db , doxygen , icu , libevent , libkrb5 , lm_sensors , net-snmp , nspr , nss , openldap , openssl , pcre , perl , perlPackages , pkg-config , python3 , svrcore , zlib , enablePamPassthru ? true , pam , enableCockpit ? true , rsync , enableDna ? true , enableLdapi ? true , enableAutobind ? false , enableAutoDnSuffix ? false , enableBitwise ? true , enableAcctPolicy ? true , enablePosixWinsync ? true </ins> }: stdenv.mkDerivation rec { pname = "389-ds-base"; <del> version = "1.3.9.1"; </del> <ins> version = "2.0.5"; </ins> <del> src = fetchurl { url = "https://releases.pagure.org/${pname}/${pname}-${version}.tar.bz2"; sha256 = "141iv1phgk1lw74sfjj3v7wy6qs0q56lvclwv2p0hqn1wg8ic4q6"; </del> <ins> src = fetchFromGitHub { owner = "389ds"; repo = pname; rev = "${pname}-${version}"; sha256 = "sha256-H0G8py4sB+2CSZKyCIb2TCIXOpnPx7udWUEK4Tg5TD8="; </ins> }; nativeBuildInputs = [ autoreconfHook pkg-config doxygen ]; buildInputs = [ <del> perl pam nspr nss openldap db cyrus_sasl svrcore icu net-snmp libkrb5 pcre libevent openssl python3 ] ++ (with perlPackages; [ MozillaLdap NetAddrIP DBFile ]); patches = [ (fetchpatch { name = "389-ds-nss.patch"; url = "https://aur.archlinux.org/cgit/aur.git/plain/nss.patch?h=389-ds-base&id=b80ed52cc65ff9b1d72f8ebc54dbd462b12f6be9"; sha256 = "07z7jl9z4gzhk3k6qyfn558xl76js8041llyr5n99h20ckkbwagk"; }) ]; </del> <ins> bzip2 cracklib cyrus_sasl db icu libevent libkrb5 lm_sensors net-snmp nspr nss openldap openssl pcre perl python3 svrcore zlib # tests cmocka libevent # lib389 (python3.withPackages (ps: with ps; [ setuptools ldap six pyasn1 pyasn1-modules dateutil argcomplete libselinux ])) # logconv.pl perlPackages.DBFile perlPackages.ArchiveTar ] ++ lib.optional enableCockpit rsync ++ lib.optional enablePamPassthru pam; </ins> postPatch = '' substituteInPlace Makefile.am  --replace 's,@perlpath@,$(perldir),g' 's,@perlpath@,$(perldir) $(PERLPATH),g' <ins> patchShebangs ./buildnum.py ./ldap/servers/slapd/mkDBErrStrs.py </ins> ''; preConfigure = ''

Related discussion:
text: Project description Upgrade 389-ds-base Apparenty its new 1.4.4.4 release is a bit different. Metadata homepage URL: source URL:
I marked this as stale due to inactivity. &rarr;
Code change:
<ins> { stdenv , cmake , fetchurl , python # GNU Octave needs KLU for ODE solvers , suitesparse , liblapack , gfortran , lapackSupport ? true }: let liblapackShared = liblapack.override { shared = true; }; in stdenv.mkDerivation rec { pname = "sundials"; version = "2.7.0"; buildInputs = [ python ] ++ stdenv.lib.optionals (lapackSupport) [ gfortran suitesparse ]; nativeBuildInputs = [ cmake ]; src = fetchurl { url = "https://computation.llnl.gov/projects/${pname}/download/${pname}-${version}.tar.gz"; sha256 = "01513g0j7nr3rh7hqjld6mw0mcx5j9z9y87bwjc16w2x2z3wm7yk"; }; patches = [ (fetchurl { # https://github.com/LLNL/sundials/pull/19 url = "https://github.com/LLNL/sundials/commit/1350421eab6c5ab479de5eccf6af2dcad1eddf30.patch"; sha256 = "0g67lixp9m85fqpb9rzz1hl1z8ibdg0ldwq5z6flj5zl8a7cw52l"; }) ]; cmakeFlags = [ "-DEXAMPLES_INSTALL_PATH=${placeholder "out"}/share/examples" ] ++ stdenv.lib.optionals (lapackSupport) [ "-DSUNDIALS_INDEX_TYPE=int32_t" # GNU Octave needs KLU for ODE solvers "-DKLU_ENABLE=ON" "-DKLU_INCLUDE_DIR=${suitesparse}/include" "-DKLU_LIBRARY_DIR=${suitesparse}/lib" "-DLAPACK_ENABLE=ON" "-DLAPACK_LIBRARIES=${liblapackShared}/lib/liblapack${stdenv.hostPlatform.extensions.sharedLibrary};${liblapackShared}/lib/libblas${stdenv.hostPlatform.extensions.sharedLibrary}" ]; # flaky tests, and patch in https://github.com/LLNL/sundials/pull/21 doesn't apply cleanly for sundials_3 doCheck = false; checkPhase = "make test"; meta = with stdenv.lib; { description = "Suite of nonlinear differential/algebraic equation solvers"; homepage    = https://computation.llnl.gov/projects/sundials; platforms   = platforms.all; maintainers = with maintainers; [ flokli idontgetoutmuch ]; license     = licenses.bsd3; }; } </ins>

Related discussion:
text: I'm trying to build octave with QT5 and with GUI (of course, when I try to build it with GUI, right?). Unfortunately, after the build: Apply this patch: and then system: host os: multi-user?: sandbox: version: channels(m): nixpkgs:
I just noticed that I do not even get the GUI feature when building octave from nixpkgs (neither nor has a GUI).
Pinging: touched the package recently, is the maintainer of the package.
I’ll try to have a look when I have some time. I’ll let you know what I can achieve.
Here is what the configure script says:
yes, I got that and I fixed it. See for my attempt to build with Qt5 (which succeeds, but starting octave with gui fails - see PR).
Code change:
- [`kops`](https://kops.sigs.k8s.io) defaults to 1.22.4, which will enable [Instance Metadata Service Version 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) and require tokens on new clusters with Kubernetes 1.22. This will increase security by default, but may break some types of workloads. See the [release notes](https://kops.sigs.k8s.io/releases/1.22-notes/) for details. <ins> - Module authors can use `mkRenamedOptionModuleWith` to automate the deprecation cycle without annoying out-of-tree module authors and their users. </ins> ## New Services {#sec-release-22.05-new-services} - [aesmd](https://github.com/intel/linux-sgx#install-the-intelr-sgx-psw), the Intel SGX Architectural Enclave Service Manager. Available as [services.aesmd](#opt-services.aesmd.enable).

Related discussion:
text: The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors
Code change:
buildInputs = [ gnuplot <del> libxls libxlsxwriter </del> libxml2 libzip ncurses <ins> ] ++ lib.optionals xlsSupport [ libxls libxlsxwriter </ins> ]; makeFlags = [ "prefix=${placeholder "out"}" ];

Related discussion:
text: libxls, one of the optional dependencies for sc-im has 6 open CVEs for arbitrary code execution, which were reported on github 5 months ago and the issue hasn't even been responded to. I think this dependency should be made optional and probably should not be included by default. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: