jiebi/CodeConvo huggingface dataset:
Code change:
{ stdenv, fetchurl, gettext, bzip2 }: stdenv.mkDerivation rec { <del> name = "sysstat-12.2.0"; </del> <ins> name = "sysstat-12.2.3"; </ins> src = fetchurl { url = "http://pagesperso-orange.fr/sebastien.godard/${name}.tar.xz"; <del> sha256 = "0xc3983ccr0dwab1px2jhbgj86pfmmr29k7ggnwjwm1qigmriak1"; </del> <ins> sha256 = "0c7lcjj796fvb0abqlhkval82r9yp5kvn3vi9k823r45422xv5y1"; </ins> }; buildInputs = [ gettext ];

Related discussion:
text: , CVSSv3=9.8 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives.
merged - closing
Code change:
owner = "gorilla-devs"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-tYRs6HfFTdUZqWal9pLZ0uUNCPr3+zQz5JV2ohOLIP8="; </del> <ins> hash = "sha256-tYRs6HfFTdUZqWal9pLZ0uUNCPr3+zQz5JV2ohOLIP8="; </ins> }; <del> buildInputs = lib.optionals stdenv.isDarwin [ Security ]; </del> <ins> buildInputs = lib.optionals stdenv.isDarwin [ Security SystemConfiguration ]; </ins> cargoHash = "sha256-5ClBS42hWw3ULEG1Qn+fiM6dvJ+xS4Dusy3BCj5Cvbg=";

Related discussion:
text: Steps to reproduce the behavior: ferium cc thanks! <!-- 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]:
Code change:
pytestCheckHook ]; <ins> disabledTests = [ # See https://github.com/deepmind/chex/issues/204. "test_uninspected_checks" ]; </ins> meta = with lib; { description = "Chex is a library of utilities for helping to write reliable JAX code."; homepage = "https://github.com/deepmind/chex";

Related discussion:
text: Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tags: - -
Code change:
<ins> { lib, stdenv, fetchFromGitHub, bundlerEnv, ruby }: let gems = bundlerEnv { name = "whatweb-env"; inherit ruby; gemdir = ./.; }; in stdenv.mkDerivation rec { pname = "whatweb"; version = "0.5.5"; src = fetchFromGitHub { owner = "urbanadventurer"; repo = "whatweb"; rev = "v${version}"; sha256 = "sha256-HLF55x4C8n8aPO4SI0d6Z9wZe80krtUaGUFmMaYRBIE="; }; prePatch = '' substituteInPlace Makefile  --replace "/usr/local" "$out"  --replace "/usr" "$out" ''; buildInputs = [ gems ]; installPhase = '' runHook preInstall raw=$out/share/whatweb/whatweb rm $out/bin/whatweb cat << EOF >> $out/bin/whatweb #!/bin/sh -e exec ${gems}/bin/bundle exec ${ruby}/bin/ruby "$raw" "$@" EOF chmod +x $out/bin/whatweb runHook postInstall ''; meta = with lib; { description = "Next generation web scanner"; homepage = "https://github.com/urbanadventurer/whatweb"; license = licenses.gpl2Only; maintainers = with maintainers; [ wolfangaukang ]; platforms = platforms.unix; }; } </ins>

Related discussion:
text: Project description A scanner informing the technologies and headers a website uses. Metadata homepage URL: source URL: license: GPL-2.0 platforms: Agnostic (Darwin, Linux, Windows) See also:
I was able to build it, check it here
Thanks!
Code change:
pywaterkotte = callPackage ../development/python-modules/pywaterkotte { }; <ins> pywavefront = callPackage ../development/python-modules/pywavefront { }; </ins> pywavelets = callPackage ../development/python-modules/pywavelets { }; pywayland = callPackage ../development/python-modules/pywayland { };

Related discussion:
text: Project description Metadata homepage URL: source URL: license: BSD-3-Clause license platforms: linux The version compatible with NixOS 23.11 is 1.3.3. Below is the code for this Python package, which might be useful: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
please test edit: i tried to add a quippy command to test this, but the new nix cli doesn't construct python environments like the old cli did, and the old cli can't trivially use github pull as input...
Code change:
[aarch64-darwin]=darwin-arm64 ) <del> hashfile="$(nix-prefetch-url --print-path "https://github.com/electron/electron/releases/download/v${VERSION}/SHASUMS256.txt" 2>/dev/null | tail -n1)" headers="$(nix-prefetch-url "https://atom.io/download/electron/v${VERSION}/node-v${VERSION}-headers.tar.gz")" </del> <ins> hashfile="$(nix-prefetch-url --print-path "https://github.com/electron/electron/releases/download/v${VERSION}/SHASUMS256.txt" | tail -n1)" headers="$(nix-prefetch-url "https://artifacts.electronjs.org/headers/dist/v${VERSION}/node-v${VERSION}-headers.tar.gz")" </ins> # Entry similar to the following goes in default.nix:

Related discussion:
text: Element v1.11.0 updated to Electron 19, so we need this packaged in Nixpkgs: <!-- 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: 18.1.0 desired version: 19.0.7 <!-- 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.
When I run the script tries to download which does not exist. Do you know where to get the electron headers?
PR that brings electron19 but does not provide electron19 headers:
I believe that states that they migrated storage. So, I think the new url would be
Great find, thanks! Updated PR to include this change and electron_19 now provides the headers.
electrum_19 to master via - feel free to update your package
Code change:
<ins> diff --git a/test/CMakeLists.txt b/test/CMakeLists.txt index 8473a42..07ea873 100644 --- a/test/CMakeLists.txt +++ b/test/CMakeLists.txt @@ -112,10 +112,6 @@ function(generate_hsaco TARGET_ID INPUT_FILE OUTPUT_FILE) DEPENDS ${INPUT_FILE} clang COMMENT "Building ${OUTPUT_FILE}..." VERBATIM) -    install( -        FILES ${PROJECT_BINARY_DIR}/${OUTPUT_FILE} -        DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/${PROJECT_NAME}/tests-v1 -        COMPONENT tests) set(HSACO_TARGET_LIST ${HSACO_TARGET_LIST} ${PROJECT_BINARY_DIR}/${OUTPUT_FILE} PARENT_SCOPE) </ins>

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:
--replace '$QT_INSTALL_DOCS' "${qtbase}/share/doc" done ''; <del> nativeBuildInputs = [ qttools ]; </del> <ins> nativeBuildInputs = [ (qttools.override { withClang = true; }) ]; </ins> qtInputs = [ qtdeclarative ]; cmakeFlags = [ "-DCMAKE_MESSAGE_LOG_LEVEL=STATUS"

Related discussion:
text: Installing causes large dependencies such as and to be pulled in at run-time Steps to reproduce the behavior: that some of the large dependencies such as are pulled in. I'd expect and to be build-time dependencies, and as such shouldn't be needed at run-time The additional dependencies are being pulled in due to , which itself should be a build dependency. FWIW, declares as a make* dependency Please run and paste the result.
not the maintainer for -qt ( is), but I took a quick look at it nevertheless and it seems that gets to in the invocation for even if it is moved to . Unfortunately I don't know enough about the Qt ecosystem to tell why this is the case.
I think that the issue lies in qttools itself, for some reason after , qttools depends on clang and llvm at runtime This doesn't seem to be the case on and
qttools provides a qt plugin so wrapQtAppsHook will add to ‘QTPLUGINPATH’ automaticallyUnfortunately, the packaging of qttools is not subdivided, all output is almost in one packagethis leads to the addition of unnecessary runtime dependencies. ( Actually even may not be needed is required by and , lupdate seems to be just a optional feature dependency on clangbut is not feasiblewe have to recompile to disable this feature Splitting into multiple packages should be a better solutionqdoc/lupdate are often used to generate documentation/translations, almost no packages runtime depends on them This pr should solve the problem of qalculate-qt but this may cause some packages fail to find lupdate. it‘s not an elegant solution
I think it's easier to add a flag to qttools, and only use that variant for building the docs.
should be , set can prevent qttools from being recognized as a runtime dependency the pull request to disable clang-based c++ parser by default
If that helps, maybe is no longer necessary?
For this issue, yes But not sure if there is a package need qttools (qt plugin ) as runtime dependency
I checked all packages that depends on qttools, and found that most if not all of them have a runtime reference on qttools due to it being in . So this problem is actually widespread, we can have the workaround in for now.
Code change:
in assert lib.all (p: p.enabled -> ! (builtins.elem null p.buildInputs)) plugins; stdenv.mkDerivation rec { <del> version = "2.6"; </del> <ins> version = "2.7"; </ins> pname = "weechat"; src = fetchurl { url = "https://weechat.org/files/src/weechat-${version}.tar.bz2"; <del> sha256 = "1narazk28m7lmn1vqi7bhyvnr8apjrmaa4w1hbadn64hwr8ya1hb"; </del> <ins> sha256 = "00hzchzw1w2181kczcrrnj8ngml3bwk7qciha3higxq3qynf0h8c"; </ins> }; outputs = [ "out" "man" ] ++ map (p: p.name) enabledPlugins;

Related discussion:
text: Currently we have two expressions that both build the kernel, whose only interface differences are in whether or not the .config is generated or provided. These builds should be merged with the two different interfaces simply being two ways to call the same underlying function, reducing code duplication and allowing the generic kernel builds to benefit from the IMO better structure of the newer manual kernel builds.
+1 on getting rid of duplication What is the "better structure"?
Structure may have been the wrong word, but the manual kernel build uses multiple outputs (suboptimally currently, which was part of the problem with the old PR) and uses the official kernel build system for building and installing, while the generic one (last I checked) had a manually maintained shell script to handle the install and parts of the build.
Fixed by
Code change:
in assert lib.all (p: p.enabled -> ! (builtins.elem null p.buildInputs)) plugins; stdenv.mkDerivation rec { <del> version = "2.6"; </del> <ins> version = "2.7"; </ins> pname = "weechat"; src = fetchurl { url = "https://weechat.org/files/src/weechat-${version}.tar.bz2"; <del> sha256 = "1narazk28m7lmn1vqi7bhyvnr8apjrmaa4w1hbadn64hwr8ya1hb"; </del> <ins> sha256 = "00hzchzw1w2181kczcrrnj8ngml3bwk7qciha3higxq3qynf0h8c"; </ins> }; outputs = [ "out" "man" ] ++ map (p: p.name) enabledPlugins;

Related discussion:
text: For example: If this is called with instead of , it will fail to produce a output. This causes an assertion of the form: Unfortunately, doesn't keep the build directory around, making the source of the problem difficult to debug.
This is more of an issue for Thanks for reporting though!
Whoops! Is there an easy way to move it?
Not that I know of, sorry.
Fixed, thanks!
Code change:
in assert lib.all (p: p.enabled -> ! (builtins.elem null p.buildInputs)) plugins; stdenv.mkDerivation rec { <del> version = "2.6"; </del> <ins> version = "2.7"; </ins> pname = "weechat"; src = fetchurl { url = "https://weechat.org/files/src/weechat-${version}.tar.bz2"; <del> sha256 = "1narazk28m7lmn1vqi7bhyvnr8apjrmaa4w1hbadn64hwr8ya1hb"; </del> <ins> sha256 = "00hzchzw1w2181kczcrrnj8ngml3bwk7qciha3higxq3qynf0h8c"; </ins> }; outputs = [ "out" "man" ] ++ map (p: p.name) enabledPlugins;

Related discussion:
text: migrated from python branch issue tracker
I'm closing this as it seems no longer relevant. From what I could find, python-virtinst is "CLI tools for building virtual machines using libvirt". But it is now merged with virtmanager: <-- contains one single file named MERGEDWITHVIRTMANAGER
Code change:
]; passthru.optional-dependencies = { <del> speedup = [ </del> <ins> speedups = [ </ins> kasa-crypt orjson ];

Related discussion:
text: python-kasa recently updated to 0.6.x from 0.5.x. The home-assistant project does not yet support 0.6.x, as a result kasa functionality is degraded. Using HomeAsisstant from latest nixpkgs, attempt to get emeter data from kasa devices. I reported this issue upstream and they advised on the version issue. There are more logs visible there. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I guess that if we would run the unit tests then the issue with 0.6.0 would have been detected.
Code change:
] ++ stdenv.lib.optionals (targetPlatform.isDarwin && targetPlatform.isAarch64) [ # fix for iOS: https://www.reddit.com/r/haskell/comments/4ttdz1/building_an_osxi386_to_iosarm64_cross_compiler/d5qvd67/ "--disable-large-address-space" <del> ] ++ stdenv.lib.optional enableDwarf [ "--enable-dwarf-unwind" </del> ]; # Make sure we never relax`$PATH` and hooks support for compatability.

Related discussion:
text: Our can no longer link executables. For example: This issue is present in current versions of . Compiling and linking works fine with an older revision, say . It looks like this might be related to some change in binutils, maybe?
This is probably from
Yes, it is. came to the same conclusion.
This probably is GHC bug though. Things like gmp and libiconv get their paths hardcoded so this isn't a problem. I would expect the same treatment for elfutils. should provide a arg.
/cc
I guess now I know why there's a patch in branch.
I'll reopen the PR fixing the linking issues.
I opened while we wait on upstream fix.
Which one, from
Yes, although it doesn't help. See
Yes, it would have surprised me a bit if it helped against that symptom -- my patch fixes that DWARF-enabling is skipped completely.
I'm surprised this worked for you back then and now there are linking errors.
Code change:
<del> { stdenv, fetchFromGitHub, cmake, boost, openssl, asio }: </del> <ins> { stdenv, fetchFromGitHub, cmake, boost, openssl }: </ins> stdenv.mkDerivation rec { pname = "cpp-netlib";

Related discussion:
text: Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:
Code change:
# Thsese are the original flags from the helm makefile buildFlagsArray = '' <del> -ldflags= </del> <ins> -ldflags=-X k8s.io/helm/pkg/version.Version=v${version} </ins> -w -s '';

Related discussion:
text: If I install , then I get version , which causes problems with Tiller image pulls. Alternatively, if I try to pull a specific version like this: Then I get this build failure:
Code change:
patchCnfLua "./texmfcnf.lua" <ins> mkdir $out/share/texmf-local </ins> rm updmap.cfg ) '' +

Related discussion:
text: TEXMF defines the order in which files are read in The idea is that TEXMFSYSVAR and TEXMFCONFIG files take precedence over files distributed with TEXMFDIST, so there is a way for the user to override configuration files. Our lists: This seems all fine, except that our derivation also makes TEXMFLOCAL point to TEXMFDIST as well, and this destroys override-ability. My suggestion is to use a separate and empty $out/share/texmf-local for TEXMFLOCAL.
Could you please provide an example of the override that doesn't work?
I dropped my customization here: It boils down to adding a custom package (minionpro availble for my ) and running: in postBuild.
I investigated your override. I see that you sneak the original , then add your font to it and regenerate the mappings which go to share/texmf-var. At the same time our texlive setup just reuses prebuilt maps provided by (for pdftex), individual font packages and others and those are installed into share/texmf which happens to be also pointed by TEXMFLOCAL. I also now discover that the line does nothing for us. Your change makes sense to me. Makes me wonder if we could do better. For example, not deleting should not hurt anything. I could not find any way to automatically scan for new entries for The Gentoo documentation mentions [1] concatenating it from /etc/texmf/updmap.d. [1]
First of all thank you for taking such a careful look at my code snippet. I really appreciate it! First, yes, I sneak out and later sneak back in. I do think that there are no adverse side-effects from not deleting in texlive.combine. I will submit a PR to remove it. This will minimize my postBuild override to just: That looks much cleaner :) As there is no real "hooks" functionality in our texlive package derivation, it seems to be a good idea to optimistically merge (by concatenation) separate snippets. I will file a separate issue to discuss this.
Thank you!
Code change:
halftone = callPackage ../applications/graphics/halftone { }; <ins> halloy = callPackage ../applications/networking/irc/halloy { }; </ins> harminv = callPackage ../development/libraries/science/chemistry/harminv { }; igrep = callPackage ../tools/text/igrep {

Related discussion:
text: Project description Halloy is an open-source IRC client written in Rust, with the Iced GUI library. It aims to provide a simple and fast client for Mac, Windows, and Linux platforms. Metadata homepage URL: source URL: license: GPL-3.0 platforms: unix, linux, darwin
Code change:
<ins> { lib, buildGoModule, fetchFromGitHub }: buildGoModule rec { pname = "headscale"; version = "0.2.2"; src = fetchFromGitHub { owner = "juanfont"; repo = "headscale"; rev = "v${version}"; sha256 = "0iij4hdbdplai5c8kvcwiw11idrk04xbpwb3njdhqcg6pdyx3216"; }; vendorSha256 = "sha256-8MCSN8wn2Y9ejHAIEwTdIXGITaa+FqX7WUMJEr0RcIk="; # Ldflags are same as build target in the project's Makefile # https://github.com/juanfont/headscale/blob/main/Makefile ldflags = [ "-s" "-w" "-X main.version=v${version}" ]; meta = with lib; { description = "An implementation of the Tailscale coordination server"; homepage = "https://github.com/juanfont/headscale"; license = licenses.bsd3; maintainers = with maintainers; [ nkje ]; }; } </ins>

Related discussion:
text: Project description An open source implementation of the Tailscale control server Metadata homepage URL: source URL: license: bsd platforms: linux
Code change:
stdenv.mkDerivation rec { pname = "gnunet"; <del> version = "0.14.0"; </del> <ins> version = "0.14.1"; </ins> src = fetchurl { url = "mirror://gnu/gnunet/${pname}-${version}.tar.gz"; <del> sha256 = "sha256-2u9gO9Mu0dM1yixcaqOnZcDfGcp69dc5CH5tkl6vRas="; </del> <ins> sha256 = "1hhqv994akymf4s593mc1wpsjy6hccd0zbdim3qmc1y3f32hacja"; </ins> }; enableParallelBuilding = true;

Related discussion:
text: Describe the bug To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers and edited it last Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I really have no idea, contains it, even bumping gnunet-gtk to be the same release version still doesn't fix it.
Have you tried applying
Code change:
, propagateDoc ? cc != null && cc ? man , extraTools ? [], extraPackages ? [], extraBuildCommands ? "" , nixSupport ? {} <del> , isGNU ? false, isClang ? cc.isClang or false, gnugrep ? null </del> <ins> , isGNU ? false, isClang ? cc.isClang or false, isCcache ? cc.isCcache or false, gnugrep ? null </ins> , buildPackages ? {} , libcxx ? null }:

Related discussion:
text: Describe the bug hides clang arguments in a "response file" by default if is true, but ccache does not support this and responds with "no input files" instead. Additional context The following workaround can be used to disable response files in a result , fixing the issue: Notify maintainers Maintainer information:
I've run into this issue as well. Edit: my bad, that doesn't work; we need the env var to be set before the outer layer of stdenv wrapper machinery runs. By the time we're in the ccache wrapper it's too late. It's also not clear to me if this is a bug in or intended behavior (I was not able to find an issue for it upstream) but it's definitely reproducible: