jiebi/CodeConvo huggingface dataset:
Code change:
<ins> { lib , rustPlatform , fetchCrate }: rustPlatform.buildRustPackage rec { pname = "swc"; version = "0.91.19"; src = fetchCrate { pname = "swc_cli"; inherit version; sha256 = "sha256-BzReetAOKSGzHhITXpm+J2Rz8d9Hq2HUagQmfst74Ag="; }; cargoSha256 = "sha256-1U9YLrPYENv9iJobCxtgnQakJLDctWQwnDUtpLG3PGc="; buildFeatures = [ "swc_core/plugin_transform_host_native" ]; meta = with lib; { description = "Rust-based platform for the Web"; homepage = "https://github.com/swc-project/swc"; license = licenses.asl20; maintainers = with maintainers; [ dit7ya ]; }; } </ins>

Related discussion:
text: Project description swc is the "speedy web compiler" fast alternative to tsc, to compile typescript to javascript without type-checking swc is mentioned in a different context in adds 150 MByte to node_modules so it makes sense to factor-out swc to a global package example use: () on a 2x2GHz machine, swc is 10x faster than tsc = 2 minutes vs 20 minutes is a lightweight wrapper (1 MByte or so) but has as peer-dependency, so npm will install both Metadata homepage URL: source URL: license: apl2 platforms: all
Code change:
sha256 = "sha256-IG5YWwq3WVzQBvAslQ9Z2Ou6ADzf4n9NkQCtH4Jgkac="; }; <del> mvnSha256 = "7Sm1hAoi5xc4MLONOD8ySLLkpao0qmlMRRva/8zR210="; </del> <ins> mvnSha256 = "WAB15d4UvUOkBXT7K/hvAZWOE3V1Lpl/tr+AFNBM4FI="; </ins> mvnParameters = "-P desktop,all-platforms"; <del> fetchedMavenDeps = stdenv.mkDerivation { name = "dbeaver-${version}-maven-deps"; inherit src; buildInputs = [ maven ]; buildPhase = "mvn package -Dmaven.repo.local=$out/.m2 ${mvnParameters}"; # keep only *.{pom,jar,sha1,nbm} and delete all ephemeral files with lastModified timestamps inside installPhase = '' find $out -type f  -name *.lastUpdated -or  -name resolver-status.properties -or  -name _remote.repositories  -delete ''; # don't do any fixup dontFixup = true; outputHashAlgo = "sha256"; outputHashMode = "recursive"; outputHash = "sha256-WAB15d4UvUOkBXT7K/hvAZWOE3V1Lpl/tr+AFNBM4FI="; }; </del> nativeBuildInputs = [ copyDesktopItems makeWrapper

Related discussion:
text: The dbeaver package does not build on . Steps to reproduce the behavior: Dbeaver should build <details<summaryTruncated build log</summary<br</details
Code change:
(enableFeature enablePython2Library "python-library") (enableFeature enablePython2Library "python2") # XXX: python2 library does not work anyway (enableFeature enableUI "ui") <ins> "--enable-gtk4" </ins> "--enable-install-tests" "--with-unicode-emoji-dir=${unicode-emoji}/share/unicode/emoji" "--with-emoji-annotation-dir=${cldr-emoji-annotation}/share/unicode/cldr/common/annotations"

Related discussion:
text: Upstream ibus-1.5.24 (in nixpkgs) supports gtk4. It will be good if we enable gtk4 support in nixpkgs. I fail to enable it with the following patch.
Code change:
]; preCheck = if stdenv.isDarwin then '' <del> export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH''${DYLD_LIBRARY_PATH:+:}`pwd`/lib </del> <ins> export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH''${DYLD_LIBRARY_PATH:+:}`pwd`/lib:${blas}/lib:${lapack}/lib </ins> '' else '' export LD_LIBRARY_PATH=$LD_LIBRARY_PATH''${LD_LIBRARY_PATH:+:}`pwd`/lib '' + ''

Related discussion:
text: Describe the bug To Reproduce Expected behavior The derivation to build an executable called Additional context It fails with also but succeeds with but so 1.3 seems to be a recent addition even though julia is on 1.4 and about to move to 1.5. Notify maintainers Metadata Please run and paste the result.
Same issue here: system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: This prevents installing GNU octave on MacOS.
FWIW I was able to work around this issue by creating a to disable the checks in arpack: I was able to build octave successfully with that. I had to hack around a runtime issue finding , will log that as a separate issue.
Code change:
]; preCheck = if stdenv.isDarwin then '' <del> export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH''${DYLD_LIBRARY_PATH:+:}`pwd`/lib </del> <ins> export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH''${DYLD_LIBRARY_PATH:+:}`pwd`/lib:${blas}/lib:${lapack}/lib </ins> '' else '' export LD_LIBRARY_PATH=$LD_LIBRARY_PATH''${LD_LIBRARY_PATH:+:}`pwd`/lib '' + ''

Related discussion:
text: Describe the bug I'd like to build the python numpy package on an x86 machine for the armv7 architecture. numpy requires liblapack and blas, which require gfortran I already fixed one issue which is that liblapack couldn't find the gfortran compiler (see the overlay below) I'm trying to use the 20.03 release, latest commit. Here's what I'm running exactly: To Reproduce Steps to reproduce the behavior: -build here's the error I get Expected behavior The derivation builds Metadata Please run and paste the result. Maintainer information:
Maybe related to: ?
I'm not getting this in NixOS. It looks like a sandboxing issue. Can you try running this:
Thanks for responding! I launched this build on NixOs using an AMI on EC2 and I get the same result as in the issue report, here are the system details:
A similar issue exists on unstable when building for x86. Currently on: system: host os: multi-user?: sandbox: version: channels(root): channels(swflint): nixpkgs:
Code change:
services.k3s.enable = true; services.k3s.role = "server"; services.k3s.extraFlags = toString [ <del> # "--kubelet-arg=v=4" # Optionally add additional args to k3s </del> <ins> # "--debug" # Optionally add additional args to k3s </ins> ]; } ```

Related discussion:
text: K3s module example option () is causing a crash because kubelet verbosity can no longer be updated post-initialization k3s does not start with the option "--kubelet-arg=v=4" defined Suggest any other k3s option except this one <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
setuptools ]; <ins> postFixup = lib.optionalString (!stdenv.targetPlatform.isWindows) '' find $out -name '*.exe' -delete ''; </ins> pythonImportsCheck = [ "distlib" "distlib.database"

Related discussion:
text: Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems. You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: In the context of pip we previously deleted these files,
Code change:
buildPhase = if buildPhase != null then buildPhase else '' runHook preBuild agda ${includePathArgs} ${everythingFile} <ins> rm ${everythingFile} ${lib.interfaceFile Agda.version everythingFile} </ins> runHook postBuild ''; installPhase = if installPhase != null then installPhase else '' runHook preInstall mkdir -p $out <del> find -not ( -path ${everythingFile} -or -path ${lib.interfaceFile everythingFile} ) -and ( ${concatMapStringsSep " -or " (p: "-name '*.${p}'") (extensions ++ extraExtensions)} ) -exec cp -p --parents -t "$out" {} + </del> <ins> find ( ${concatMapStringsSep " -or " (p: "-name '*.${p}'") (extensions ++ extraExtensions)} ) -exec cp -p --parents -t "$out" {} + </ins> runHook postInstall '';

Related discussion:
text: Describe the bug The new version of Agda is working fine on other systems, but not NixOS. I've reported a bit more about what is known at To Reproduce Steps to reproduce the behavior: Agda 2.6.1 any file (e.g, ) Expected behavior Agda checks the file quickly and exits. Additional context Issue in the Agda repository: agda/agda Metadata Maintainer information:
I believe that this is fixed by rework of our Agda setup ! (Which is included in the most recent nixos-unstable.) Can you confirm? :-) $ echo module Main where && time agda Checking Main (). real 0m0.132s user 0m0.104s sys 0m0.028s Looks reasonable!
I haven't had chance to test the new stuff, but this issue probably should be closed anyway, as it's being worked on upstream (). I'm doing fine now using the workaround of adding option .
Code change:
RUST_SRC_PATH = rustPlatform.rustcSrc; postInstall = '' <del> wrapProgram $out/bin/racer --set-default RUST_SRC_PATH $rustcSrc </del> <ins> wrapProgram $out/bin/racer --set-default RUST_SRC_PATH ${rustPlatform.rustcSrc} </ins> ''; checkPhase = ''

Related discussion:
text: Current version of rustracer 2.1.22 does not build with latest stable rust (see ). Please update rustracer to the newest version 2.1.27
Code change:
<del> [tool.poetry] name = "rmfuse-env" version = "0.1.0" description = "" authors = [] [tool.poetry.dependencies] python = "^3.8" rmfuse = {git = "https://github.com/rschroll/rmfuse.git", extras = ["pyfuse3"]} [tool.poetry.dev-dependencies] [build-system] requires = ["poetry-core>=1.0.0"] build-backend = "poetry.core.masonry.api" </del>

Related discussion:
text: The version of pillow rmfuse uses is vulnerable to CVE-2022-.
Since rmfuse is packaged using poetry2nix you are basically the only one willing to update it or its dependencies. That's problematic given that you don't do so even two weeks after being notified of a vulnerability.
I don't think interacting in this way is very constructive. There are different points of view regarding packaging Python packages, that's it. That an issue like this does not get picked up is not strange, people are typically busy. If you like to I suppose you could add the CVE to the expression. Whether the CVE can be considered a security issue in case of rmfuse should be considered as well.
Why not? I'm just articulating a problem with the way rmfuse is packaged right now that is obviously an actual problem. It's not technical though, just organizational.
Code change:
"-DENABLE_VOMS=${if stdenv.isLinux then "TRUE" else "FALSE"}" ]; <del> # Workaround the library-not-found issue # happening to binaries compiled with xrootd libraries. # See #169677 preFixup = '' makeWrapperArgs+=("--prefix" "${lib.optionalString stdenv.hostPlatform.isDarwin "DY"}LD_LIBRARY_PATH" ":" "${placeholder "out"}/lib") ''; postFixup = '' while IFS= read -r FILE; do wrapProgram "$FILE" "''${makeWrapperArgs[@]}" done < <(find "$bin/bin" -mindepth 1 -maxdepth 1 -type f,l -perm -a+x) '' + lib.optionalString (externalEtc != null) '' </del> <ins> postFixup = lib.optionalString (externalEtc != null) '' </ins> moveToOutput etc "$etc" ln -s ${lib.escapeShellArg externalEtc} "$out/etc" ''; <ins> dontPatchELF = true; # shrinking rpath will cause runtime failures in dlopen </ins> meta = with lib; { description = "High performance, scalable fault tolerant data access"; homepage = "https://xrootd.slac.stanford.edu";

Related discussion:
text: XRootD failed to access the files following the URL, complaining that isn't found and the authentication handler couldn't be loaded. However, does present in the output directory. Steps to reproduce the behavior: Enter the top directory of Nixpkgs See Run See the detailed output A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Terminal output during execution: Short: Long: is packaged by myself, but I haven't found the solution. Suggestions and helps are more than welcom. Please run and paste the result.
This is probably because has the wrong . How to fix that though? No idea.
Code change:
attrsets.nameValuePair name fixedDrv; # versionedDerivations :: AttrSet Derivation <del> versionedDerivations = builtins.listToAttrs (lists.map buildPackage perSystemReleases); </del> <ins> versionedDerivations = builtins.listToAttrs (lists.map buildPackage allReleases); </ins> defaultDerivation = { ${pname} = (buildPackage newest).value; }; in

Related discussion:
text: should have only eliminated the s and removed some of the platform-based (adding new broken/non-buildable attrs), but instead has changed the actual logic. Since that commit, no longer resolves into but into (note the wrong cuda release), later leading to evaluation errors This currently breaks on Steps to reproduce the behavior: We should probably add some tests for the selection logic as well... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. 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]:
Code change:
<del> { stdenv, fetchsvn, fetchurl, cups, zlib }: </del> <ins> { stdenv, fetchsvn, cups, zlib, jbigkit }: </ins> let rev = "315"; in stdenv.mkDerivation rec { name = "splix-svn-${rev}"; src = fetchsvn { # We build this from svn, because splix hasn't been in released in several years # although the community has been adding some new printer models.

Related discussion:
text: I have a Samsung M2022W (usb) that works on a raspberrypi using raspbian (2017-11-29-raspbian-stretch-). I had to pick the ML-2160 driver in CUPS 2.2.1 as recommended by On NixOS (cups-2.2.2): [nawal nix-info system: "x8664-linux", multi-user?: yes, version: nix-env (Nix) 1.11.16, channels(nawal): "nixos-17.03-17.03.1082.", channels(root): "nixos-17.09.3149.", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs If I use services.printing = { enable = true; drivers = [ pkgs.samsungUnifiedLinuxDriver ]; extraConf = '' LogLevel debug ''; extraFilesConf = '' FileDevice yes ''; }; and pick the same driver, I get garbage printed out. I tried to track down the ppd on raspbian, but only found: pi $ grep 2160 /usr/share/cups/drv/splix- ModelName "ML-2160" PCFileName "" and (i.e. it generated the ppd when I installed the printer apparently).
Code change:
<del> { stdenv, fetchsvn, fetchurl, cups, zlib }: </del> <ins> { stdenv, fetchsvn, cups, zlib, jbigkit }: </ins> let rev = "315"; in stdenv.mkDerivation rec { name = "splix-svn-${rev}"; src = fetchsvn { # We build this from svn, because splix hasn't been in released in several years # although the community has been adding some new printer models.

Related discussion:
text: On nixos: [nawal | grep 2160 /nix/store/6f2zx8dl4w0kzgw3wj8f466mvkcgc3dc-samsung-UnifiedLinuxDriver-4.00.39/opt/share/ppd/ML- /nix/store/nmp023llc8fix567f413a5rqbx4sw45g-cups-progs/share/cups/model/ML- Having diffed them, I notice amongst a huge number of differences: [nawal diff /nix/store/nmp023llc8fix567f413a5rqbx4sw45g-cups-progs/share/cups/model/ML- | grep Version < FileVersion: "2.0.0" < PSVersion: "(3010.000) 0" < QPDL QPDLVersion: "3" < *cupsVersion: 2.2 so raspbian is using a version "2.0.0" and "2.2" of something or other, whereas nixos is using a version "1.2" and "1.1" of similar things. I managed to get my printer to work by copying the ppd across, but I don't understand enough of cups (nor now have the inclination to learn) to figure out what's going on or how to make nixos do the right thing (i.e. in a word, print). I thought this might be useful for someone else who wants to pick it up? Happy to hack around the raspbian if you need more info, or try out things if you need me to while the sd card contains raspbian.
Can you find out what package on Raspbian provides the driver? Have you installed proprietary Samsung driver there? If not, can you try removing ? It seems we have latest version of but not the latest of the proprietary driver but you don't seem to use it.
I'll have a look tomorrow evening - how do i use the new splix without upgrading everything to the same commit?
Find out your current commit with (look at the suffix), then clone nixpkgs repository (), checkout current commit (), fetch my changes () and cherry-pick my patch atop your current commit (). Then you can rebuild nixpkgs with .
I can confirm this works.
Code change:
<del> { stdenv, fetchsvn, fetchurl, cups, zlib }: </del> <ins> { stdenv, fetchsvn, cups, zlib, jbigkit }: </ins> let rev = "315"; in stdenv.mkDerivation rec { name = "splix-svn-${rev}"; src = fetchsvn { # We build this from svn, because splix hasn't been in released in several years # although the community has been adding some new printer models.

Related discussion:
text: Thanks for the detailed instructions and for fixing it so quickly! NB: I had to do: (i.e. ) thanks
Code change:
<ins> From Ingo Hadan <ingo.hadan@sdm.de> Fri, 02 Apr 2010 21:08:50 +0200 From: Julien Moutinho <julm+tsocks@autogeree.net> Date: Fri, 26 Apr 2013 01:57:26 +0200 Subject: tsocks fails if socksified application uses poll(2) (e.g. subversion-1.5) --- diff --git a/tsocks.c b/tsocks.c index 9cfdfff..470babd 100644 --- a/tsocks.c +++ b/tsocks.c @@ -657,10 +657,11 @@ int poll(POLL_SIGNATURE) { * be ready for writing), otherwise we'll just let the select loop * come around again (since we can't flag it for read, we don't know * if there is any data to be read and can't be bothered checking) */ -            if (conn->selectevents & WRITE) { -               setevents |= POLLOUT; +            if (conn->selectevents & POLLOUT) { +               ufds[i].revents |= POLLOUT; nevents++; } +            ufds[i].events = conn->selectevents; } } } while (nevents == 0); </ins>

Related discussion:
text: The tsocks package creates a shell script () that can be used to run a command with set to the tsocks library. However, it is hard-coded to use . It should be changed to use .
Fixed by
Code change:
libsodium ]; <del> propagatedBuildInputs = [ </del> <ins> propagatedNativeBuildInputs = [ </ins> cffi ]; <ins> propagatedBuildInputs = [ six ]; </ins> checkInputs = [ hypothesis pytestCheckHook

Related discussion:
text: The package can't be cross compiled to other architectures, tested: raspberry-pi and aarch-multiplatform Steps to reproduce the behavior: It should be compiled. This doesn't seem to a nix-only problem, but still influenced by nix. Doesn't compile on arm: AIX: Some missing support for aarch64: Doesn't compile via qemu for arm32v7 and arm64v8: The error I'm having doesn't seem to show up anywhere else though. And a few of those threads also post work arounds. There is no maintainer. $ nix-shell -p nix-info --run "nix-info -m" this path will be fetched (0.05 MiB download, 0.28 MiB unpacked): /nix/store/xq77wmzk8d306anyk9rsvl4i4h7ihchw-bash-interactive-4.4-p23-dev copying path '/nix/store/xq77wmzk8d306anyk9rsvl4i4h7ihchw-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): channels(nix): nixpkgs: Maintainer information:
It seems to be that every package that declares in it's is failing to cross compile. If I put it in it fails with another error though: Should I open another, conglomerate, issue for all the other packages?
Code change:
{ buildPackages, runCommand, nettools, bc, bison, flex, perl, rsync, gmp, libmpc, mpfr, openssl <del> , libelf, cpio, elfutils </del> <ins> , libelf, cpio, elfutils, zstd, gawk </ins> , writeTextFile }:

Related discussion:
text: The latest major version 5.9 of the Linux kernel . Apparently, zstd compressed things decompress much faster and can cut boot times substantially, hence it seems worthwhile for us to support this scheme. Currently we are using bzip2. Unfortunately, I probably won't find time to work on this myself, but thought to open this issue to track progress.
I've [probably] been using it through a xanmod patch, not recently since the 5.9 release though. What I have in my files are and adding to of the kernel derivation
For the initrd image: For me (which might differ from the stock kernel NixOS provides): is already enabled, so set This enables ZSTD compression for initrd. However, which will need to as mentioned above.
I was wondering if zstd should be made a part of stdenv. are all available in stdenv on linux and with slowly becoming more common by being available in the kernel and used by various distribution's packaging it should make sense to include it.
Can this be closed? Did cover it all?
Yes, it did! Closing this issue. Thank you for pointing that out, didn't notice before.
Code change:
proprietary_codecs = false; use_sysroot = false; use_gnome_keyring = gnomeKeyringSupport; <del> ## FIXME remove use_gconf after chromium 65 has become stable use_gconf = gnomeSupport; </del> use_gio = gnomeSupport; enable_nacl = enableNaCl; <del> enable_hotwording = enableHotwording; </del> enable_widevine = enableWideVine; use_cups = cupsSupport;

Related discussion:
text: When building chromium with args like this and the gn args aren't known/accepted by chromium (like the above one actually is that is still given incorrectly in 18.03), it will print: but continue to build anyway, which can be super surprising when your build doesn't do what you expect. We should catch that when building. Unfortunately doesn't seem to have a feature to warn. But we can run to see the in stdout and grep for it: I have confirmed that only seems to work that way when giving a build target, like . CC
Suggestion: We switch to
PR
pull request was merged.
Code change:
''; }); <ins> stumpwm-unwrapped = super.stumpwm; </ins> ltk = super.ltk.overrideLispAttrs (o: { src = pkgs.fetchzip { url = "https://github.com/uthar/ltk/archive/f19162e76d6c7c2f51bd289b811d9ba20dd6555e.tar.gz";

Related discussion:
text: Since PM stumpwm is now up to date but I have an issue in stumpwm module loading. SBCL will return the a package conflict error between packages "CLOSER-COMMON-LISP" and "DYNAMIC-MXINS" Steps to reproduce the behavior: to your stumpwm contrib modules in an appropriate directory a minimal file: reboot using stumpwm or refresh the stumpwm config using command (by default keystrokes are: ) Modules are loaded as expected Results of :
Hm, indeed. And maybe for debugging we should provide access to the «library» version of StumpWM…
We could try building using the Makefile instead of save-lisp-and-die. I did, but then there were problems with missing HOME. Then the problem was that the stumpwm build script seems to want to remember the value of HOME from compile-time on run-time (something like "/build") How did stumpwm work previously in nixpkgs?
Can you try with this?
Code change:
cabal2nix = self.generateOptparseApplicativeCompletions [ "cabal2nix" ] super.cabal2nix; arbtt = overrideCabal (drv: { <ins> buildTools = drv.buildTools or [] ++ [ pkgs.buildPackages.installShellFiles pkgs.buildPackages.libxslt ]; postBuild = '' xsl=${pkgs.buildPackages.docbook_xsl}/share/xml/docbook-xsl make -C doc man XSLTPROC_MAN_STYLESHEET=$xsl/manpages/profile-docbook.xsl ''; postInstall = '' for f in doc/man/man[1-9]/*; do installManPage $f done ''; </ins> # The test suite needs the packages's executables in $PATH to succeed. preCheck = '' for i in $PWD/dist/build/*; do

Related discussion:
text: I've to my . itself works fine: But the man pages are all missing: As far as I can tell, upstream provides them in DocBook format: and also provides a Makefile to build them: so this should hopefully be easily fixable. Steps to reproduce the behavior: . to read a man page for any of the binaries. Man pages should be provided. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for reporting I have opened PR to fix it.