jiebi/CodeConvo huggingface dataset:
Change:
<ins> diff -ur compiler-rt-5.0.2.src/cmake/builtin-config-ix.cmake compiler-rt-5.0.2.src-patched/cmake/builtin-config-ix.cmake --- compiler-rt-5.0.2.src/cmake/builtin-config-ix.cmake	2017-05-25 00:53:24.000000000 +0900 +++ compiler-rt-5.0.2.src-patched/cmake/builtin-config-ix.cmake	2020-05-10 03:24:24.937433155 +0900 @@ -24,7 +24,7 @@ set(ARM64 aarch64) -set(ARM32 arm armhf armv6m armv7m armv7em armv7 armv7s armv7k) +set(ARM32 arm armhf armv6m armv7m armv7em armv7 armv7s armv7k armv7l) set(X86 i386 i686) set(X86_64 x86_64) set(MIPS32 mips mipsel) diff -ur compiler-rt-5.0.2.src/lib/builtins/CMakeLists.txt compiler-rt-5.0.2.src-patched/lib/builtins/CMakeLists.txt --- compiler-rt-5.0.2.src/lib/builtins/CMakeLists.txt	2017-07-13 04:33:30.000000000 +0900 +++ compiler-rt-5.0.2.src-patched/lib/builtins/CMakeLists.txt	2020-05-10 03:24:45.945075423 +0900 @@ -444,6 +444,7 @@ set(armv7_SOURCES ${arm_SOURCES}) set(armv7s_SOURCES ${arm_SOURCES}) set(armv7k_SOURCES ${arm_SOURCES}) +set(armv7l_SOURCES ${arm_SOURCES}) set(arm64_SOURCES ${aarch64_SOURCES}) # macho_embedded archs </ins>

Discussion:
Describe the bug A clear and concise description of what the bug is. Same issue as or , but on armv7l Additional context Add any other context about the problem here. On hydra, the clang build first started failing with this error after going from to . I diffed the range and found to be the most likely culprit. It enabled some cmakeFlags globally which used to only be enabled on darwin and useLLVM systems. I don't know what exactly these do but, I was able to build on my rpi2 by disabling them on aarch32: Since I have no idea why this works and what would be affected, I'd rather have someone look over this. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
we probably need to add armv7l here:
I tried but it fails with this error now: I guess it can't find a default target for armv7l somehow? Not really familiar with cmake unfortunately
I made some progress, it seems to be taking the target arch from the triplet given to , even if you override the target arch with a flag. Printf debugging showed me that it does this halfway through the configure phase, it's armhf in the beginning if I set the flag. Setting the compiler target to instead of makes it find its target and compile successfully. Does have any importance outside the build process?
I don't think it does. It's possible it sets in compiler calls, but that is considered equivalent to .
Change:
stdenv.mkDerivation rec { pname = "mosquitto"; <del> version = "1.6.5"; </del> <ins> version = "1.6.6"; </ins> src = fetchFromGitHub { owner  = "eclipse"; repo   = "mosquitto"; rev    = "v${version}"; <del> sha256 = "0scgsi3rvs9s8vxv4r7d5d9ixbsfg4dwnjcy6zxwdz9dfn8qnngj"; </del> <ins> sha256 = "01a1vf0rgncmhk7v9vnj4gdx0j8jfiy95f2hr4iwqdch7jy5q367"; </ins> }; postPatch = ''

Discussion:
Mosquitto 1.6.6 is available and addresses a security vulnerability (that is already publicly disclosed unfortunately, otherwise I would be using the proper channels) - sorry for the short amount of time from the last version.
Change:
[mcfgthreads]="mcfgthreads/mcfgthread-12.dll" ) <del> declare -A targets=([d3d9]=1 [d3d11]=1 [dxgi]=1) </del> <ins> declare -A targets=([d3d8]=1 [d3d9]=1 [d3d11]=1 [dxgi]=1) </ins> # Option variables

Discussion:
Package name: dxvk Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2.3.1 Current version on the stable/release channel: 2.3.1 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
meta = with lib; { description = "TUI framework for Python inspired by modern web development"; homepage = "https://github.com/Textualize/textual"; <ins> changelog = "https://github.com/Textualize/textual/releases/tag/v${version}"; </ins> license = licenses.mit; maintainers = with maintainers; [ joelkoen ]; };

Discussion:
Package name: textual Latest released version: 0.23.0 <!-- Search your package here: --- Current version on the unstable channel: 0.15.1 Current version on the stable/release channel: <!-- 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.
Does resolve this?
As far as I can tell: yes. Would be great to have it merged into master (so it shows up in nixpkgs-unstable at some point).
And of course there have been two new releases in the meantime....
Was fixed, closing.
Change:
i686 = "FV/OVMF"; x86_64 = "FV/OVMF"; aarch64 = "FV/AAVMF"; <ins> riscv64 = "FV/RISCV_VIRT"; </ins> }; in

Discussion:
Steps to reproduce the behavior: OVMF for host double "riscv64-linux" on a non-riscv64 machine failure This seems to be due to there Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Would you mind trying to patch this and submit a PR? I know has risc-v, but I don't and it would take me a long time to bootstrap it on my x64 system.
Sorry, I didn't intend to just disappear on this one. Hopefully this gets merged soon though. Thank you
Change:
denaro = callPackage ../applications/finance/denaro { }; <ins> inherit (callPackage ../development/tools/devpod { }) devpod devpod-desktop; </ins> dfasma = libsForQt5.callPackage ../applications/audio/dfasma { }; dfilemanager = libsForQt5.callPackage ../applications/file-managers/dfilemanager { };

Discussion:
Project description DevPod is a client-only tool to create reproducible developer environments based on a on any backend. Metadata homepage URL: source URL: license: Mozilla Public License 2.0 platforms: unix, linux
I have opened PR and I would love some help with testing and reviewing :pray:
Change:
fi if (( "${NIX_CC_USE_RESPONSE_FILE:-@use_response_file_by_default@}" >= 1 )); then <del> responseFile=$(mktemp --tmpdir cc-params.XXXXXX) </del> <ins> responseFile=$(mktemp "${TMPDIR:-/tmp}/cc-params.XXXXXX") </ins> trap 'rm -f -- "$responseFile"' EXIT printf "%qn"  ${extraBefore+"${extraBefore[@]}"} 

Discussion:
The , which . I do not have a short reproducer. However, the issue was observed on in a cgo context. The issue can be resolved by applying the following change to : The error should not have occurred. The code under test used to work, and failed after an update of the nixpkgs revision in use from to . n/a The commit range includes the following two commits that touch on : adds to the strip setup-hook adds to the cc-wrapper for response file handling The latter one seems to be the cause of the issue. Similar issues were described in and <!-- 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.
So the wrapper picks up the binary from the system instead of the one from the store because the environment is not pure? This makes the behavior of this and other wrappers unpredictable. Maybe it would be better to make sure that the tools used in the wrapper are actually from its real runtime dependencies in the store?
Yes, that matches my understanding. Yes, that thought crossed my mind, too. However, I saw that there is an , which is then . And this import and seems to be . I don't know the context or reasoning for all this logic and didn't venture there. But, that may very well also be a good solution.
Ah cool! So it basically already works that way. Setting actually enables the import. Your explanation led me to find where this logic was first introduced. The discussion there is very interesting, afaiu we need to restore to its original value so things like linker scripts will still find the intended executables. I think that the commit that introduced the should have it before the path gets restored.
Oh, I see, thanks! I overlooked one negation. That seems like it could solve the issue, too. Perhaps it's easier to just resolve before the is reset and then still invoke it later, since . I had opened that replaces the invocation by a portable one. That approach was easier to test in my use-case without rebuilding the world.
Change:
makeFlags = [ "PREFIX=$(out)" "RSTTOMAN=${docutils}/bin/rst2man.py" "VERBOSE=1" ]; <ins> postInstall = '' wrapProgram "$out/bin/zathura" --prefix PATH ":" "${file}/bin" ''; </ins> meta = { homepage = http://pwmt.org/projects/zathura/; description = "A core component for zathura PDF viewer";

Discussion:
i created a fresh for a python repo i use, i forgot a few dependencies the install process fetches them while happyly breaking building wheels i expected to get a hard failure i believe should not use pip to install packages branch in the repo upcoming System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) :
you have network access (which you do in a ) then yes, any program can fetch. This is expected and will happen with more programs. should we install packages? Saying that we shouldn't do a certain thing without further argumentation nor alternatives isn't very constructive.
for 1. i would expect no network action possible while building the environment (in order to stay reasonably close to the real env) as for installing python packages, it i believe it should be much saver to have a wheel as a output, and use that to generate a target folder unfortunately im not sure how to prototype such a pip-free builder - there would be a need for a stage1 set of setuptools/wheel packages to bootstrap setuptools/wheel wheels and go with the rest
How would you do that in ? Anyway, that is something to discuss on the Nix tracker, not here. By default we build wheels, and then install the wheels. The wheels can be build in different ways. We could use but we have certain arguments we pass to and I don't know whether accepts those. Building the wheel, and installing the wheel is already separated. We only use for installing the wheel. If would be sufficient we could get rid of . Bootstrapping isn't such a big problem; that's basically just unzipping the wheels as we do already.
(triage) Needs closing? :)
There is no good alternative so closing.
Change:
</arg> <arg> <del> <option>--verbose</option> </del> <ins> <option>--all</option> </ins> </arg> <arg> <del> <option>--xml</option> </arg> <arg choice="plain"> </del> <replaceable>option.name</replaceable> </arg> </cmdsynopsis>

Discussion:
We can currently display a NixOS module option type using, for example: . It seems to me that, to maximize usability, should display this string. Also, the should display this information. Perhaps it should be toggleable, though, since options involving submodule types could be quite large. EDIT: Apparently the field is currently for any submodule type. It would be nice to either pretty-print the whole type or output some kind of structured data there. Run . There is no indication of the type of this option other than the default/example values. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc
This was fixed in .
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Change:
mkDerivation rec { pname = "calibre"; <del> version = "5.30.0"; </del> <ins> version = "5.31.1"; </ins> src = fetchurl { url = "https://download.calibre-ebook.com/${version}/${pname}-${version}.tar.xz"; <del> sha256 = "058dqqxhc3pl4is1idlnc3pz80k4r681d5aj4a26v9acp8j7zy4f"; </del> <ins> sha256 = "sha256-3LGEWuHms54ji9GWSyLl8cFWIRBqHY1Jf/CNPJOywrU="; </ins> }; <del> # https://sources.debian.org/patches/calibre/5.30.0+dfsg-1 </del> <ins> # https://sources.debian.org/patches/calibre/5.31.1+dfsg-1 </ins> patches = [ #  allow for plugin update check, but no calibre version check (fetchpatch { <del> name = "0001_only_plugin_update.patch"; url = "https://sources.debian.org/data/main/c/calibre/${version}%2Bdfsg-1/debian/patches/0001-only-plugin-update.patch"; sha256 = "sha256-aGT8rJ/eQKAkmyHBWdY0ouZuWvDwtLVJU5xY6d3hY3k="; </del> <ins> name = "0001-only-plugin-update.patch"; url = "https://raw.githubusercontent.com/debian-calibre/calibre/debian/${version}%2Bdfsg-1/debian/patches/0001-only-plugin-update.patch"; sha256 = "sha256-dLzO1TWP7Q4nw2a3oN7qlhGCmcA0NKJrZidUnD6hUMA="; </ins> }) ] ++ lib.optional (!unrarSupport) ./dont_build_unrar_plugin.patch;

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: calibre <!-- 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: 5.30.0 desired version: 5.31.1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: The URL for returns 404 (). It seems like Debian removed the 5.30.0 URL and now only has those for 5.31.1. Please tag this issue in your PR.
Change:
hamster-time-traker = throw "hamster-time-tracker has been removed from nixpkgs, as it was unmaintained."; # added 2019-12-10 heimdalFull = heimdal; # added 2018-05-01 hepmc = hepmc2; # added 2019-08-05 <ins> hexen = throw "hexen (SDL port) has been removed: Abandoned by upstream."; # added 2019-12-11 </ins> hicolor_icon_theme = hicolor-icon-theme; # added 2018-02-25 htmlTidy = html-tidy;  # added 2014-12-06 iana_etc = iana-etc;  # added 2017-03-08

Discussion:
Package: hexen Error: Makefile:157: recipe for target 'mmisc.o' failed Platform: openSUSE 13.1, x8664, XFCE Version: nix-env (Nix) 1.9
It builds fine for 32bit x86 architectures. I’ve no idea if it runs however. I don’t know if this program has been ever meant to be built on x86_64.
Hmm, that's a good point. If it isn't meant to run on x86_64, would there be some way to indicate as such in the file, eg. using an ?
Setting the attribute to should be enough.
The i686 version builds for me but doesn't run.
(triage) status?
Still doesn't build on x64.
(triage) and now?
Still fails on on NixOS 18.03.
Then I suggest we remove it. Can you prepare a patch?
Change:
bracketsEnv = buildEnv { name = "env-brackets"; paths = [ <del> gtk2 glib gdk_pixbuf stdenv.cc.cc alsaLib nss nspr gconf cups libgcrypt_1_5 dbus systemd.lib </del> <ins> gtk2 glib gdk_pixbuf stdenv.cc.cc.lib alsaLib nss nspr gconf cups libgcrypt_1_5 dbus.lib systemd.lib </ins> ]; }; in stdenv.mkDerivation rec { name = "brackets-${version}"; <del> version = "1.5"; </del> <ins> version = "1.7"; </ins> src = fetchurl { url = "https://github.com/adobe/brackets/releases/download/release-${version}/Brackets.Release.${version}.64-bit.deb"; <del> sha256 = "1fc8wvh9wbcydd1sw20yfnwlfv7nllb6vrssr6hgn80m7i0zl3db"; </del> <ins> sha256 = "0nsiy3gvp8rd71a0misf6v1kz067kxnszr5mpch9fj4jqmg6nj8m"; </ins> name = "${name}.deb"; }; <del> phases = [ "installPhase" ]; </del> <ins> phases = [ "installPhase" "fixupPhase" ]; </ins> buildInputs = [ makeWrapper ];

Discussion:
Launching after installation yields the following error: In a terminal: → nix-env -iA nixos.brackets → brackets System:
Let me take a look. I think is skipping the
I fixed the package and gave you an update while I was at it :) See the linked PR
Thanks, it works like charm.
Change:
-                                  "libssl.so")) -  (:cygwin (:or "cygssl-1.1.dll" "cygssl-1.0.0.dll")) -  (t (:default "libssl3"))) <del> +  (t "@openssl@/lib/libssl.so")) </del> <ins> +  (t "@libssl@")) </ins> (unless (member :cl+ssl-foreign-libs-already-loaded *features*)

Discussion:
The output from building the target on macOS: Note that if I hack the patch file associated with the derivation to use a extension, it builds fine.
The should be changed to a placeholder and then the placeholder should be replaced with
Change:
platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "19mf9f5zx23cjjn0p77wz1igzpfr22mxhljgavffl8fwqq74v4ih"; </del> <ins> sha256 = "01ldw5ba6xfn2k97n75n52qs4f0fy8xmn58c4247xf476nfvg035"; </ins> type = "gem"; }; <del> version = "3.2.5"; </del> <ins> version = "3.2.6"; </ins> }; power_assert = { groups = ["default" "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:
description = "Diablo build for modern operating systems"; longDescription = "In order to play this game a copy of diabdat.mpq is required. Place a copy of diabdat.mpq in ~/.local/share/diasurgical/devilution before executing the game."; license = licenses.unlicense; <del> maintainers = [ maintainers.karolchmist ]; </del> <ins> maintainers = with maintainers; [ karolchmist aanderse ]; </ins> platforms = platforms.linux ++ platforms.windows; }; }

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: devilutionx <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.2.1 desired version: 1.3.0 <!-- 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. There are a number of changes in the new version, many of which make it difficult to package for nixpkgs.
Change:
## Defaults declare -A dlls=( <ins> [d3d8]="dxvk/d3d8.dll" </ins> [d3d9]="dxvk/d3d9.dll" [d3d10]="dxvk/d3d10.dll dxvk/d3d10_1.dll dxvk/d3d10core.dll" [d3d11]="dxvk/d3d11.dll"

Discussion:
Package name: dxvk Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2.3.1 Current version on the stable/release channel: 2.3.1 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
buildGoModule rec { pname = "mutagen-compose"; <del> version = "0.16.5"; </del> <ins> version = "0.17.1"; </ins> src = fetchFromGitHub { owner = "mutagen-io"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-Rn3aXwez/WUGpuRvA6lkuECchpYek8KDMh6xzZOV9v0="; </del> <ins> hash = "sha256-B1UpN9lNMmWe4FtKos2RAGb0ef3xODeGrjD2MwkAYAI="; </ins> }; <del> vendorHash = "sha256-EkLeB2zUJkKCWsJxMiYHSDgr0/8X24MT0Jp0nuYebds="; </del> <ins> vendorHash = "sha256-uILyJV6Lc4zZeqSl9JMlcUYAs0jDblsIPQKwgg2WOX8="; </ins> doCheck = false; subPackages = [ "cmd/mutagen-compose" ]; <ins> tags = [ "mutagencompose" ]; </ins> meta = with lib; { <del> broken = stdenv.isDarwin; </del> description = "Compose with Mutagen integration"; homepage = "https://mutagen.io/"; changelog = "https://github.com/mutagen-io/mutagen-compose/releases/tag/v${version}";

Discussion:
Mutagen crashes: Steps to reproduce the behavior: No crash Please run and paste the result.
Change:
<del> unpackCmdHooks+=(_tryUnrar) _tryUnrar() { if ! [[ "$curSrc" =~ .rar$ ]]; then return 1; fi unrar x "$curSrc" >/dev/null } </del>

Discussion:
Package name: unrar Latest released version: 7.00 beta 3 Current version on the unstable channel: 6.2.12 Current version on the stable/release channel: 6.2.12 I receive more and more RAR files which are created with Unrar 7.00 beta versions / require a more recent version tan 6.2.12 I would appreciated if the existing unrar package can be updated or a new unrar-beta package be proposed .. Changelog : Notify maintainers
There was an automatic update in that I marked as draft, exactly because it's in beta. I'd much rather add a new package. what do you think?
I don't think we should update to the beta either. Sometimes I think about adding beta and release candidate versions to package , but that would be a nixpkgs policy discussion.
If people are still creating new RAR files then I don't want to be maintainer of this package. Stop using RAR.