jiebi/CodeConvo huggingface dataset:
Change:
<del> { stdenv, fetchurl, libtool }: </del> <ins> { stdenv, fetchurl, fetchpatch, libtool }: </ins> stdenv.mkDerivation rec { pname = "libtomcrypt";

Discussion:
, CVSSv3=9.1 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
Change:
description = "A hackable text editor for the 21st Century"; homepage = https://atom.io/; license = licenses.mit; <del> maintainers = [ maintainers.offline maintainers.nequissimus ]; </del> <ins> maintainers = [ maintainers.offline maintainers.nequissimus maintainers.ysndr ]; </ins> platforms = [ "x86_64-linux" ]; }; }

Discussion:
I tried to push with the integrated git features but got this error: Folder with git repository some changes, commit and try to push of pushing, you get this error Atom: 1.12.1 system: host os: multi-user?: sandbox: version: nixpkgs:
Got the same issue here.
Still reproducible after 18.03 release. system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs: It was fixed before, but it seems the path has changed.
Change:
runConfigPath = "/run/rslsync/config.json"; <del> createConfig = pkgs.writeShellScriptBin "create-resilio-config" '' ${pkgs.jq}/bin/jq  '.shared_folders |= map(.secret = $ARGS.named[.dir])'  ${ lib.concatMapStringsSep " n  " (entry: ''--arg '${entry.dir}' "$(cat '${entry.secretFile}')"'') sharedFoldersSecretFiles }  <${configFile}  >${runConfigPath} ''; </del> <ins> createConfig = pkgs.writeShellScriptBin "create-resilio-config" ( if cfg.sharedFolders != [ ] then '' ${pkgs.jq}/bin/jq  '.shared_folders |= map(.secret = $ARGS.named[.dir])'  ${ lib.concatMapStringsSep " n  " (entry: ''--arg '${entry.dir}' "$(cat '${entry.secretFile}')"'') sharedFoldersSecretFiles }  <${configFile}  >${runConfigPath} '' else '' # no secrets, passing through config cp ${configFile} ${runConfigPath}; '' ); </ins> in {

Discussion:
introduced storing secrets outside of the nix store, but does not handle the case where the webui manages all of the secrets, and is an empty list. this will run with a null argument.
Second PR to fix the same bug:
Change:
"ARM" else if stdenv.isAarch64 then "AARCH64" <ins> else if stdenv.hostPlatform.isRiscV64 then "RISCV64" </ins> else throw "Unsupported architecture";

Discussion:
Steps to reproduce the behavior: pkgsCross.aarch64-multiplatform.edk2 Full log here: Few last lines: EDK2 package was updated in nixpkgs, and after that cross-compilation from x86_64 to aarch64 stopped working. The issue appeared in latest update commit: The package has no maintainers set in meta. The breaking change was introduced by: I see cross-compilation fixes have been made previously by: Other contributors who have contributed over the past year, I got from and : "Sandro Jäckel" and Please run and paste the result.
Actually I had binfmt for aarch64-linux emulated, I disabled it and now build fails even earlier when it tries to run antlr built for aarch64-linux:
Unable to reproduce: I just cross compiled EDK2 with .
Wait, I had a dinosaur nixpkgs there on a feature branch, testing again.
I concur, antlr is trying to be executed but it's not a binary for the right platform. This seems to be a breakage upstream as they seem to ship their own ANTLR binaries.
I won't have time to tackle it as I have too much on my plate right now.
Any change on looking at this now as we are going towards NixOS 23.11?
Thank you!
Change:
# Resources in the jar can't be found, workaround copied from AUR cp -r build/resources $out/share/java/jabref <del> # workaround for https://github.com/NixOS/nixpkgs/issues/162064 </del> tar xf build/distributions/JabRef-${version}.tar -C $out --strip-components=1 <del> unzip $out/lib/javafx-web-*-linux${lib.optionalString stdenv.isAarch64 "-aarch64"}.jar libjfxwebkit.so -d $out/lib/ </del> <ins> # remove openjfx libs for other platforms rm $out/lib/javafx-*-win.jar ${lib.optionalString stdenv.isAarch64 "$out/lib/javafx-*-linux.jar"} # workaround for https://github.com/NixOS/nixpkgs/issues/162064 unzip $out/lib/javafx-web-*.jar libjfxwebkit.so -d $out/lib/ </ins> DEFAULT_JVM_OPTS=$(sed -n -E "s/^DEFAULT_JVM_OPTS='(.*)'$/1/p" $out/bin/JabRef | sed -e "s|$APP_HOME|$out|g" -e 's/"//g') rm $out/bin/*

Discussion:
The program Jabref will build, but give a JFX related error upon trying to run the program. Steps to reproduce the behavior: The program launches as it used to. Please run and paste the result.
It's fixed in but hasn't been merged.
Hi. Sorry for digging this up, but I'm having the same error for starting a JFX application inside Intellij IDEA, where is unable to find (or ). My hack to resolve this involves: Make sure that there is within your ( for example) Add the path to :Start Intellij IDEA from the shell. I felt like this is worth a separate issue (Intellij and JFX related), but wanted to ask it here first. Many thanks!
I can't understand what you want to ask... This issue is caused by the reason said in
I meant I had the same issue (missing for ), but in another context, and was wondering instead of that hacky workaround, is there any way to make my JFX application starts with no error.
Change:
, gobject-introspection , gtk-layer-shell , gtk3 <ins> , gvfs </ins> , json-glib , libgee , libhandy <ins> , libnotify </ins> , libpulseaudio , librsvg , meson

Discussion:
(still as of at the time of writing, but ever since ) is missing the runtime dependency which, , is required to fix (which is the issue I am experiencing). Please take a look at the original issue on the upstream repository linked prior, as everything mentioned there is identical (to the behaviour on my machine). I have read on the and which I saw was left unresponded. This issue was opened to hopefully clear up the need for this missing dependency. This is my first time contributing to , so I want to apologise in advance in case I am doing anything wrong here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
feel free to patch the package, I can't look into it :(
Change:
<ins> #!/usr/bin/env nix-shell #!nix-shell -i bash -p curl gnused nix-prefetch jq set -e dirname="$(dirname "$0")" updateHash() { version=$1 arch=$2 os=$3 hashKey="${arch}-${os}_hash" url="https://github.com/Readarr/Readarr/releases/download/v$version/Readarr.develop.$version.$os-core-$arch.tar.gz" hash=$(nix-prefetch-url --type sha256 $url) sriHash="$(nix hash to-sri --type sha256 $hash)" sed -i "s|$hashKey = "[a-zA-Z0-9/+-=]*";|$hashKey = "$sriHash";|g" "$dirname/default.nix" } updateVersion() { sed -i "s/version = "[0-9.]*";/version = "$1";/g" "$dirname/default.nix" } currentVersion=$(cd $dirname && nix eval --raw -f ../../.. readarr.version) # We cannot use the latest releases as in the past Readarr released old version with v2.0 and then went back to 0.1 latestTag=$(curl https://api.github.com/repos/Readarr/Readarr/releases | jq -r ".[0].tag_name") latestVersion="$(expr $latestTag : 'v(.*)')" if [[ "$currentVersion" == "$latestVersion" ]]; then echo "Readarr is up-to-date: ${currentVersion}" exit 0 fi updateVersion $latestVersion updateHash $latestVersion x64 linux updateHash $latestVersion arm64 linux updateHash $latestVersion x64 osx </ins>

Discussion:
Readarr Readarr is a ebook collection manager for Usenet and BitTorrent users. It can monitor multiple RSS feeds for new books from your favorite authors and will interface with clients and indexers to grab, sort, and rename them. Metadata homepage URL: source URL: license: GNU GPL v3 platforms: Windows, Linux, macOS, Raspberry Pi, etc.
As you bundled some of the *arr software earlier, I'd be interested in trying out to package readarr, however I have 0 experience with these kind of package and the dotnet environment. Would one of you be willing to help me?
Pretty much the same tbh, I'd honestly just start with a copy of one of the existing snippets and change the appropriate parts.
Change:
xorg.xkbcomp ]; <ins> binPath = lib.makeBinPath requiredTools; </ins> gstDeps = with gst_all_1; [ gst-libav gst-plugins-bad

Discussion:
<!-- 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: lutris-unwrapped <!-- 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: 0.5.8.4 desired version: 0.5.9 <!-- 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.
Change:
patches = [ ./urw-font-files.patch ./doc-no-ref.diff <ins> (fetchpatch { name = "CVE-2019-6116"; url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=d3537a54740d78c5895ec83694a07b3e4f616f61"; sha256 = "1hr8bpi87bbg1kvv28kflmfh1dhzxw66p9q0ddvbrj72qd86p3kx"; }) </ins> ]; outputs = [ "out" "man" "doc" ];

Discussion:
, (nixos-unstable, nixos-19.03, nixos-18.09) Scanned versions: nixos-unstable: ; nixos-19.03: ; nixos-18.09: . May contain false positives.

Can't simply apply the upstream commits, unfortunately (AFAICT). This looks pretty serious!
Thank you!! :sparkle:
Change:
}; version = "2.2.3"; }; <ins> rack-attack = { dependencies = ["rack"]; groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "1rc6simyql7ax5zzp667x6krl0xxxh3asc1av6gcn8j6cyl86wsx"; type = "gem"; }; version = "6.6.0"; }; </ins> rack-livereload = { dependencies = ["rack"]; groups = ["development" "test"];

Discussion:
, CVSSv3=7.5 (nixos-unstable) CVSSv3=7.5 (nixos-unstable) A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification. A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages. Scanned versions: nixos-unstable: . Cc Cc Cc
Change:
<del> args : with args; let version = "1.5.0"; in rec { src = fetchurl { url = "mirror://sourceforge/pidgin-latex/pidgin-latex_${version}.tar.bz2"; sha256 = "9c850aee90d7e59de834f83e09fa6e3e51b123f06e265ead70957608ada95441"; }; buildInputs = [texLive pkgconfig gtk imagemagick glib pidgin which]; configureFlags = []; installFlags = [ "PREFIX=$out" ]; preBuild = fullDepEntry ('' mkdir -p $out/bin ln -s $(which convert) $out/bin ln -s $(which xelatex) $out/bin ln -s $(which dvips) $out/bin sed -e 's/-Wl,-soname//' -i Makefile sed -e 's/(PATH(")latex/1xelatex/' -i LaTeX.c sed -e 's/|| execute(cmddvips, dvipsopts, 10) //' -i LaTeX.c sed -e 's/  strcat([*]file_ps, "[.]ps");/  strcat(*file_ps, ".pdf");/' -i LaTeX.c sed -e 's/([*]convertopts[5]=[{]")("",)/1 -trim 2/' -i LaTeX.c sed -e 's/(#define HEADER ".*)12pt(.*)"/116pt2usepackage{fontspec}usepackage{xunicode}"/' -i LaTeX.h '') ["minInit" "addInputs" "defEnsureDir" "doUnpack"]; postInstall = fullDepEntry ('' mkdir -p $out/lib mkdir -p $out/share/pidgin-latex ln -s ../../lib/pidgin/LaTeX.so  $out/share/pidgin-latex '') ["minInit" "defEnsureDir" "doMakeInstall"]; /* doConfigure should be specified separately */ phaseNames = [ "preBuild" "doMakeInstall" "postInstall"]; name = "pidgin-latex-${version}"; meta = { description = "LaTeX rendering plugin for Pidgin IM"; priority = "10"; }; } </del>

Discussion:
This, and "meta" should probably be filled to enable Hydra builds.
, maybe you can look at this?
The project is on now, and our version looks outdated for years.
I've dropped one version of a plugin and updated and cleaned up another.

Describe the bug After switching my NixOS configuration to use the rebuild failed at rebuilding . Trying to rebuild again (continuing at again) caused the same issue. Tried after setting in my local nixpkgs clone, and that has worked without errors. I've uploaded the log of to . ~The has triggered a rebuild of other packages so I don't have a failing log available (yet).~ EDIT: gist updated with nixos-rebuild log. Looks like there is a difference / error in the detection. has been able to reproduce this (non-deterministically), so I'm curious what his easy reproducer is. To Reproduce Steps to reproduce the behavior: reproducer TBD Expected behavior Package should build. Additional context Add any other context about the problem here. Metadata Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I’m not sure of why exactly this causes the subsequent errors, but is a direct consequence of . My reproducer is simply (where the flake is with ). The reason why it wasn’t deterministic for me is that the second machine in which I tried to build it had the first one as a substituter, so the derivation hadn’t been built locally but had been fetched − and as such wasn’t affected by NixOS/nix .
Didn't realize there was a targeted fix in the nix repo yet, but I've attempted to rebuild my system again with and without any substituters. Took about 36h, but rebuilding the world worked this time.
Change:
, qtdeclarative , protobuf , grpc <ins> , patches ? [] </ins> }: qtModule { pname = "qtgrpc"; qtInputs = [ qtbase qtdeclarative ]; buildInputs = [ protobuf grpc ]; <ins> inherit patches; </ins> }

Discussion:
Steps to reproduce the behavior: on nixos-unstable channel Add any other context about the problem here.
Change:
stdenv.mkDerivation { pname = targetPrefix + (if name != "" then name else "${ccName}-wrapper"); <del> version = if cc == null then null else ccVersion; </del> <ins> version = if cc == null then "" else ccVersion; </ins> preferLocalBuild = true;

Discussion:
Describe the bug I'm getting from some Nix packages. /nix/store/8br3hnwahahpi4m3s9xjd34xn18bf1l4-source/pkgs/stdenv/generic/make- Here -Originated from: Is it because it should be Expected behavior No error nix-env version is 2.11.0 Additional context Add any other context about the problem here.
I ran into the same issue when I tried to use nix-darwin with flakes. The example was using an old version of nixpkgs-darwin. Changing it to use the latest version seemed to fix it. I made a PR to update the readme: LnL7/nix-darwin .
Same problem on OpenBSD The trace
Can be reproduced on linux with: ` Edit: The problem is in cc-native which seems to be rotted over time because we didn't add a new system for a longer time. The problem is that cc-native has not version attr. Trying to find a fix for that right now.
can you move this to nixpkgs?
Change:
inherit (darwin.apple_sdk.frameworks) Foundation; }; <ins> dnd-tools = callPackage ../applications/misc/dnd-tools { }; </ins> inherit (callPackage ../applications/virtualization/docker {}) docker_20_10;

Discussion:
Project description DnD tools is a set of interactive CLI tools for DnD, a RPG. Metadata source URL: license: AGPL-3.0 platforms: cross-platform dependencies: python (runtime)
I'll give it a shot.
Change:
buildInputs = [ makeWrapper <ins> ] ++ lib.optionals requireSageTests [ </ins> # This is a hack to make sure sage-tests is evaluated. It doesn't acutally # produce anything of value, it just decouples the tests from the build. sage-tests

Discussion:
Is it possible to load additional python libraries when using sage. For example, if I want to load , how do I do so? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Possible solution
Change:
hash = "sha256-p7rGc9qiRs9U/7SKET6t0gSmFWMOdrU7X2TYGidbd7M="; }; <ins> nativeBuildInputs = [ perlPackages.perl ]; </ins> buildInputs = with perlPackages; [ perl IOStringy TestOutput ]; doCheck = true;

Discussion:
Steps to reproduce the behavior: . E.g.: The problem occurs because adding perl to does not add it to for cross compilation. I'm not entirely sure if perl is needed to build the derivation, but adding perl to nativeBuildInputs solves the problem: Note that this issue might exist for other packages too. Related forum post: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Thanks for report this Ill look into it shortly
Change:
''; }; <ins> # see https://github.com/NixOS/nixpkgs/issues/237521 for this particular test testTomlSemantics = { drv = evalFormat formats.toml {} { processors = { override = [ { tags = { cluster = "staging"; }; } ]; rename = [ { replace = [ { dest = "ceph_telegraf_check"; measurement = "exec"; } ]; } ]; }; }; expected = '' [processors] [[processors.override]] [processors.override.tags] cluster = "staging" [[processors.rename]] [[processors.rename.replace]] dest = "ceph_telegraf_check" measurement = "exec" ''; }; </ins> # This test is responsible for #   1. testing type coercions #   2. providing a more readable example test

Discussion:
changed behaviour between nixos 22.11 and NixOS 23.05, apparently producing semantically different outputs (which broke our telegraf module) Bisect implies this is the commit that broke(?) remarshal: Was this intentional?
cc as maintainer of remarshal cc as author (I think?) of
Oh yeah that's definitely not intentional, at least from Nixpkgs side. It's unfortunate that we depend on a third-party for this.. We could pin to prevent such breakages, but we should definitely have a test case that covers this breakage.
Change:
"docs/yaml/objects/dep.yaml" ]; }) <ins> # tests: avoid unexpected failure when cmake is not installed # https://github.com/mesonbuild/meson/pull/11321 (fetchpatch { url = "https://github.com/mesonbuild/meson/commit/a38ad3039d0680f3ac34a6dc487776c79c48acf3.patch"; hash = "sha256-9YaXwc+F3Pw4BjuOXqva4MD6DAxX1k5WLbn0xzwuEmw="; }) </ins> ]; setupHook = ./setup-hook.sh; <del> # Meson included tests since 0.45, however they fail in Nixpkgs because they # require a typical building environment (including C compiler and stuff). # Just for the sake of documentation, the next lines are maintained here. doCheck = false; </del> nativeCheckInputs = [ ninja pkg-config ]; <ins> checkInputs = [ zlib ]; </ins> checkPhase = '' <del> python ./run_project_tests.py </del> <ins> patchShebangs "test cases" substituteInPlace "test cases/native/8 external program shebang parsing/script.int.in"  --replace /usr/bin/env ${coreutils}/bin/env # requires git, creating cyclic dependency rm -r "test cases/common/66 vcstag" # requires glib, creating cyclic dependency rm -r "test cases/linuxlike/6 subdir include order" rm -r "test cases/linuxlike/9 compiler checks with dependencies" # requires static zlib, see #66461 rm -r "test cases/linuxlike/14 static dynamic linkage" HOME="$TMPDIR" python ./run_project_tests.py </ins> ''; postFixup = ''

Discussion:
Hi, I can't see an update on master or a pull request. Mesa 23.0.0 seems to need a meson feature that appears to only be in meson-1.0.0 which is out. I realize bumping meson is probably a large task though, so I'm raising a flag for it now. cc: (recent committers to our meson package)
reference for mesa: without that patch the mesa-23 RC does not build (missing valgrind.h), with the patch, meson whines that its too old of a release.
Change:
let unwrapped = mkXfceDerivation { category = "xfce"; pname = "thunar"; <del> version = "4.18.10"; </del> <ins> version = "4.18.11"; </ins> <del> sha256 = "sha256-jne+jETPmM6VksdwJAxruji/GKH42iftWm74Ok9qX44="; </del> <ins> sha256 = "sha256-B417gkrU9EG4ZsEdeuH8P2v4FqYUiTwqgKcO4cSi4SI="; </ins> nativeBuildInputs = [ docbook_xsl

Discussion:
Missing dependency on breaks "Open Terminal Here" functionality Steps to reproduce the behavior:  without in that right clicking and selecting "Open Terminal Here" is broken Package should handle so users don't have to manually install Possible to fix by wrapping lines occur in <!-- 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]:
Change:
<del> <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="chap-contributing"> <title>Contributing to this documentation</title> <para> The DocBook sources of the Nixpkgs manual are in the <filename xlink:href="https://github.com/NixOS/nixpkgs/tree/master/doc">doc</filename> subdirectory of the Nixpkgs repository. </para> <para> You can quickly check your edits with <command>make</command>: </para> <screen> <prompt>$ </prompt>cd /path/to/nixpkgs/doc <prompt>$ </prompt>nix-shell <prompt>[nix-shell]$ </prompt>make $makeFlags </screen> <para> If you experience problems, run <command>make debug</command> to help understand the docbook errors. </para> <para> After making modifications to the manual, it's important to build it before committing. You can do that as follows: <screen> <prompt>$ </prompt>cd /path/to/nixpkgs/doc <prompt>$ </prompt>nix-shell <prompt>[nix-shell]$ </prompt>make clean <prompt>[nix-shell]$ </prompt>nix-build . </screen> If the build succeeds, the manual will be in <filename>./result/share/doc/nixpkgs/manual.html</filename>. </para> </chapter> </del>

Discussion:
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. to . the contents from Docbook to CommonMark. Follow . Use existing .md sections for inspiration. from the folder to build the manual. the manual on your computer at after running from doc/ folder: it looks good, submit a PR and reference this issue.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I am currently working on it :-)
I opened a PR here: Thanks in advance for reviewing :-)
I'll do the section.
Nice! I amended the issue title for correctness sake.
Change:
VERSION="${cfg.version} (${cfg.codeName})" VERSION_CODENAME=${toLower cfg.codeName} VERSION_ID="${cfg.version}" <del> PRETTY_NAME="NixOS ${cfg.version} (${cfg.codeName})" </del> <ins> PRETTY_NAME="NixOS ${cfg.release} (${cfg.codeName})" </ins> LOGO="nix-snowflake" HOME_URL="https://nixos.org/" DOCUMENTATION_URL="https://nixos.org/nixos/manual/index.html"

Discussion:
Describe the bug The NixOS version number is very long. It's good to know from which nixpkgs commit it was built. Needed for issues here. But a user don't have to know the exact version. One rather uses the release version like used in the when talking about it. The long version also leads to UI breaking. For example in the Pantheon settings about panel: ! That looks broken. I would like to have just "NixOS 19.09 (Loris)" there. I propose to use the release version in end-user facing places and the full version which includes the revision for developers and debug tools. That would mean: nixos version = "19.09" nixos full version = "19.09.1320." Use nixos version in: /etc/os-release lsb-release script Use full nixos version in: nixos-version nix-info What do you think?
Maybe just shorten the field in ?
Yes, that would be enough. is the right place: A pretty operating system name in a format suitable for presentation to the user. May or may not contain a release code name or OS version of some kind, as suitable. If not set, defaults to "PRETTYNAME="Linux"". Example: "PRETTYNAME="Fedora 17 (Beefy Miracle)"". Our lsb-release script uses that too: That should improve Pantheon about panel, Mumble and Steam (and thereby Protondb).