jiebi/CodeConvo huggingface dataset:
Change:
Describe the bug To Reproduce Steps to reproduce the behavior: Expected behavior no fail Additional context it seem to be fixed upstream, but no new release it made yet Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:

Discussion:
<del> { lib, stdenv </del> <ins> { lib , stdenv </ins> , fetchFromGitHub , nix-update-script , pantheon , pkg-config <del> , vala_0_46 </del> <ins> , vala </ins> , cmake , ninja , gtk3

, gtkspell3 , glib , libgee <ins> , pcre </ins> , sqlite , discount , wrapGAppsHook <del> , withPantheon ? false }: </del> <ins> , withPantheon ? false }: </ins> stdenv.mkDerivation rec { pname = "notes-up"; <del> version = "2.0.2"; </del> <ins> version = "unstable-2020-12-29"; </ins> src = fetchFromGitHub { owner = "Philip-Scott"; repo = "Notes-up"; <del> rev = version; sha256 = "0bklgp8qrrj9y5m77xqbpy1ld2d9ya3rlxklgzx3alffq5312i4s"; </del> <ins> rev = "2ea9f35f588769758f5d2d4436d71c4059141a6f"; sha256 = "sha256-lKOM9+s34xYB9bF9pgip9DFu+6AaxSE4HjFVhoWtttk="; </ins> }; nativeBuildInputs = [ cmake ninja <del> # fails with newer vala: https://github.com/Philip-Scott/Notes-up/issues/349 vala_0_46 </del> <ins> vala </ins> pkg-config wrapGAppsHook ];

gtkspell3 libgee pantheon.granite <ins> pcre </ins> sqlite webkitgtk ];

meta = with lib; { description = "Markdown notes editor and manager designed for elementary OS" <del> + lib.optionalString withPantheon " - built with Contractor support"; </del> <ins> + lib.optionalString withPantheon " - built with Contractor support"; </ins> homepage = "https://github.com/Philip-Scott/Notes-up"; <del> license = licenses.gpl2; </del> <ins> license = licenses.gpl2Only; </ins> maintainers = with maintainers; [ davidak ]; platforms = platforms.linux; };
Change:
Describe the bug Signing using external provider is not able to open browser for SAML authentication. To Reproduce Steps to reproduce the behavior: ./result/bin/appgate configured provider click on "sign in with provider" the error Expected behavior Browser opens to sign in. Screenshots  Additional context The strace output snippet: Notify maintainers Metadata Please run and paste the result. Maintainer information:

Discussion:
, python37Packages , stdenv , systemd <ins> , xdg-utils </ins> , zlib }: with lib;

systemd zlib ]; <del> rpath = lib.makeLibraryPath deps ; </del> <ins> rpath = lib.makeLibraryPath deps; </ins> in stdenv.mkDerivation rec { pname = "appgate-sdp";

wrapProgram $out/opt/appgate/appgate-driver --prefix PATH : ${lib.makeBinPath [ iproute2 networkmanager dnsmasq ]} wrapProgram $out/opt/appgate/linux/set_dns --set PYTHONPATH $PYTHONPATH <ins> wrapProgram $out/bin/appgate --prefix PATH : ${xdg-utils}/bin </ins> ''; meta = with lib; { description = "Appgate SDP (Software Defined Perimeter) desktop client";
Change:
Project description Command line tools for Azure Functions Existing package from here: Metadata homepage URL: source URL: license: mit platforms: unix

Discussion:
<ins> { stdenv , lib , config , fetchurl , unzip , makeWrapper , icu , libunwind , curl , zlib , libuuid , dotnetbuildhelpers , dotnetCorePackages , coreclr , openssl }: stdenv.mkDerivation rec { pname = "azure-functions-core-tools"; version = "3.0.3568"; src = fetchurl { url = "https://github.com/Azure/${pname}/releases/download/${version}/Azure.Functions.Cli.linux-x64.${version}.zip"; sha256 = "0yxdqc5d1xsixjj2dlvs32d6fz4vh58ih2l00lc456fg15mfw3lg"; }; buildInputs = [ unzip makeWrapper dotnetbuildhelpers ]; nativeBuildInputs = [ icu libunwind curl zlib dotnetCorePackages.sdk_3_1 ]; libPath = lib.makeLibraryPath [ libunwind libuuid stdenv.cc.cc curl zlib icu openssl ]; unpackPhase = '' unzip $src ''; installPhase = '' mkdir -p $out/bin cp -prd * $out/bin patchelf  --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath "${libPath}" "$out/bin/func" chmod +x $out/bin/func $out/bin/gozip find $out/bin -type f -name "*.so" -exec patchelf --set-rpath "${libPath}" {} ; wrapProgram "$out/bin/func" --prefix LD_LIBRARY_PATH : ${libPath} ''; dontStrip = true; # Causes rpath patching to break if not set meta = with lib; { homepage = "https://github.com/Azure/azure-functions-core-tools"; description = "Command line tools for Azure Functions"; license = licenses.mit; maintainers = with maintainers; [ jshcmpbll ]; platforms = platforms.linux; }; } </ins>

azure-cli = callPackage ../tools/admin/azure-cli { }; <ins> azure-functions-core-tools = callPackage ../development/tools/azure-functions-core-tools { }; </ins> azure-storage-azcopy = callPackage ../development/tools/azcopy { }; azure-vhd-utils  = callPackage ../tools/misc/azure-vhd-utils { };
Change:
Describe the bug When using and and I get a failure that I think is unexpected. To Reproduce Steps to reproduce the behavior: With the following files: and the following : I get the following error when building like so: Note that everything works fine if I simply don't have the as an entry in the list to . Expected behavior The build to succeed and to be able to see a 'doomed' file created by the root user! Notify maintainers Can't find any: But perhaps the maintainers are good: <!-- 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. Maintainer information:
I guess it has to do somehow with the fact that this command is running in a virtual machine. A "workaround" is to wrap the folder in a derivation: I don't quite know enough nix to know if this is committing some major crime of misunderstanding or something.
and I are in the "CODEOWNERS" file, and and I are in the test. Did you think of another place where maintainers could be listed? We don't have a standard attribute for attrsets or functions.

Discussion:
docker.succeed( "tar -tf ${examples.exportBash} | grep './bin/bash' > /dev/null" ) <ins> with subtest("Ensure bare paths in contents are loaded correctly"): docker.succeed( "docker load --input='${examples.build-image-with-path}'", "docker run --rm build-image-with-path bash -c '[[ -e /hello.txt ]]'", "docker rmi build-image-with-path", ) docker.succeed( "${examples.layered-image-with-path} | docker load", "docker run --rm layered-image-with-path bash -c '[[ -e /hello.txt ]]'", "docker rmi layered-image-with-path", ) </ins> ''; })

let <ins> inherit (lib) escapeShellArgs toList ; </ins> mkDbExtraCommand = contents: let contentsList = if builtins.isList contents then contents else [ contents ];

preMount = lib.optionalString (contents != null && contents != [ ]) '' echo "Adding contents..." <del> for item in ${toString contents}; do </del> <ins> for item in ${escapeShellArgs (map (c: "${c}") (toList contents))}; do </ins> echo "Adding $item..." rsync -a${if keepContentsDirlinks then "K" else "k"} --chown=0:0 $item/ layer/ done

# Example export of the bash image exportBash = pkgs.dockerTools.exportImage { fromImage = bash; }; <ins> build-image-with-path = buildImage { name = "build-image-with-path"; tag = "latest"; contents = [ pkgs.bashInteractive ./test-dummy ]; }; layered-image-with-path = pkgs.dockerTools.streamLayeredImage { name = "layered-image-with-path"; tag = "latest"; contents = [ pkgs.bashInteractive ./test-dummy ]; }; </ins> }
Change:
Describe the bug Since is always "managed by your organization". This is because the section of is always set, probably due to broken bracketing here: resulting in always containing at least: I'm not sure, but I think this broke the auto update of my addons, which are not managed by NixOS. Expected behavior Have managed firefox be completely opt-in. Author
Maybe it is time to write some tests for the complex wrapper script? Not sure if anyone has raised that before.
Thanks for reporting! Hmm I see this wasn't broken bracketing, more like unknown side effects. This should be quick to fix, I will work on it

Discussion:
}; } ) {} extensions; <del> } // { </del> <ins> } // lib.optionalAttrs usesNixExtensions { </ins> Extensions = { Install = lib.foldr (e: ret: ret ++ [ "${e.outPath}/${e.extid}.xpi" ]
Change:
Describe the bug Building the output of does not produce the exact same output each time it is build. Having bit-by-bit reproducible derivations makes auditing build processes easier. This package is especially interesting since it is part of the milestone tracked by To Reproduce Steps to reproduce the behavior: Expected behavior Success! Additional context There is an upstream patch to gi-docgen at that might help, but doesn't seem to completely fix the issue yet. Starting point:
The latest commit should address all issues, but I need help reproducing the (lack of) reproducibility. Can anyone check compiling pango before/after patching, to confirm the and diffs are now gone? Thanks.
OK managed to reproduce pango not being reproducible at HEAD. With the patch, I cannot get it to fail after multiple attempts, even under load.
It's merged!
Can confirm this fixes it here as well! PR'ed as to get the patch in for 21.05
Maybe this can be closed now?

Discussion:
url = "https://gitlab.gnome.org/jtojnar/gi-docgen/commit/08dcc31f62be1a5af9bd9f8f702f321f4b5cffde.patch"; sha256 = "vAT8s7zQ9zCoZWK+6PsxcD5/48ZAfIOl4RSNljRCGWQ="; }) <ins> # make DevHelp sections & index.json have stable ordering # already merged upstream, so patch can removed when we update # beyond 2021.2 (fetchpatch { url = "https://gitlab.gnome.org/GNOME/gi-docgen/-/commit/cc21241d4386d4f78dbcb087fd9a92899935cb5c.patch"; sha256 = "0wna8mzrlbsv7f3bc7ndqll9l105kp8kdmhbbjhbdhzzzyvh6vcw"; }) </ins> ]; nativeBuildInputs = [
Change:
<!-- 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: j <!-- 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: 901 release-f desired version: 902 release-b <!-- 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.

Discussion:
stdenv.mkDerivation rec { pname = "j"; <del> version = "901"; jtype = "release-f"; </del> <ins> version = "902"; jtype = "release-b"; </ins> src = fetchFromGitHub { owner = "jsoftware"; repo = "jsource"; rev = "j${version}-${jtype}"; <del> sha256 = "1776021m0j1aanzwg60by83n53pw7i6afd5wplfzczwk8bywax4p"; </del> <ins> sha256 = "0j67vgikqflwjqacsdicasvyv1k54s2c8vjgwmf0ix7l41p4xqz0"; </ins> name = "jsource"; };

io = callPackage ../development/interpreters/io { }; <del> j = callPackage ../development/interpreters/j {}; </del> <ins> j = callPackage ../development/interpreters/j { stdenv = clangStdenv; }; </ins> janet = callPackage ../development/interpreters/janet {};
Change:
Describe the bug I cannot install anything that depends on splinter (such as searx), as it doesn't seem cached and fails to build To Reproduce Steps to reproduce the behavior: Additional context this was on nixos-unstable ()

Discussion:
{ lib , buildPythonPackage <del> , fetchPypi </del> <ins> , fetchFromGitHub </ins> , selenium <ins> , six </ins> , flask <del> , coverage </del> <ins> , pytestCheckHook </ins> }: buildPythonPackage rec { pname = "splinter"; version = "0.14.0"; <del> src = fetchPypi { inherit pname version; sha256 = "459e39e7a9f7572db6f1cdb5fdc5ccfc6404f021dccb969ee6287be2386a40db"; </del> <ins> src = fetchFromGitHub { owner = "cobrateam"; repo = "splinter"; rev = version; sha256 = "0480bqprv8581cvnc80ls91rz9780wvdnfw99zsw44hvy2yg15a6"; </ins> }; <del> propagatedBuildInputs = [ selenium ]; </del> <ins> propagatedBuildInputs = [ selenium six ]; </ins> <del> checkInputs = [ flask coverage ]; </del> <ins> checkInputs = [ flask pytestCheckHook ]; </ins> <del> # No tests included doCheck = false; </del> <ins> disabledTestPaths = [ "samples" "tests/test_djangoclient.py" "tests/test_flaskclient.py" "tests/test_webdriver.py" "tests/test_webdriver_chrome.py" "tests/test_webdriver_firefox.py" "tests/test_webdriver_remote.py" "tests/test_zopetestbrowser.py" ]; </ins> <del> meta = { </del> <ins> pythonImportsCheck = [ "splinter" ]; meta = with lib; { </ins> description = "Browser abstraction for web acceptance testing"; homepage = "https://github.com/cobrateam/splinter"; <del> license = lib.licenses.bsd3; </del> <ins> license = licenses.bsd3; maintainers = with maintainers; [ dotlambda ]; </ins> }; }
Change:
Describe the bug The package medfile-4.1.0 fails to build on x8664 with the following error: To Reproduce Steps to reproduce the behavior: to () fails: Expected behavior Medfile should be able to build Additional context I guess the version check will be just HDF5VERSION == 1.11.*, I will look into creating a patch. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --No maintainers, but did the last meaningful change. Metadata Maintainer information:

Discussion:
inherit (python3Packages) ansi2html; }; <del> medfile = callPackage ../development/libraries/medfile { }; </del> <ins> medfile = callPackage ../development/libraries/medfile { hdf5 = hdf5_1_10; }; </ins> meilisearch = callPackage ../servers/search/meilisearch { inherit (darwin.apple_sdk.frameworks) IOKit Security;
Change:
Describe the bug GParted in the installation ISO images cannot create, resize, move and do other operations on many filesystems such as FAT32. This problem is due to absence of related (optional) run-time dependencies such as and (in the case of FAT32). in live session doesn't solve the problem. The supports to filesystems other than ext4 is important especially when you need to operate on the EFI System Partition (ESP), NTFS for Windows, HFS for Mac, and BTRFS used by some other Linux distributions. Possible solution includes: all the run-time dependencies required for GParted to operate on those filesystems in the list in . a new package, , and show it in . Replace with 'gparted-full' in list in . To Reproduce Steps to reproduce the behavior: Go to and download the 64bit Plasma Desktop ISO image, which is the image after burning it to a USB stick or attaching to a virtual machine. sure that there is a FAT32 partition on your machine. Most computers have EFI System Partition, which is usually FAT32. If there isn't any, an USB stick with a FAT32 partition can be attachede GParted and right-click on the FAT32 partition, it can be noticed that some options including are grayed out. -click on an un-allocated space, click , and it can be seen that many options including FAT32 have been grayed out. Expected behavior GParted on the ISO installation image can operate on all or most of the supported file systems. Screenshots If applicable, add screenshots to help explain your problem. Additional context Filesystems supported by GParted: 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. Maintainer information:
I had the same issue now.
Related

Discussion:
# Tools to create / manipulate filesystems. pkgs.ntfsprogs # for resizing NTFS partitions pkgs.dosfstools <ins> pkgs.mtools </ins> pkgs.xfsprogs.bin pkgs.jfsutils pkgs.f2fs-tools

{ lib, stdenv, fetchurl, intltool, gettext, coreutils, gnused, gnome , gnugrep, parted, glib, libuuid, pkg-config, gtkmm3, libxml2 , gpart, hdparm, procps, util-linux, polkit, wrapGAppsHook, substituteAll <ins> , mtools, dosfstools </ins> }: stdenv.mkDerivation rec {

preFixup = '' gappsWrapperArgs+=( <del> --prefix PATH : "${lib.makeBinPath [ gpart hdparm util-linux procps coreutils gnused gnugrep ]}" </del> <ins> --prefix PATH : "${lib.makeBinPath [ gpart hdparm util-linux procps coreutils gnused gnugrep mtools dosfstools ]}" </ins> ) '';
Change:
Buck as installed via nix reports with an older release version than the one listed in its nixpkgs My guess is that is probably the correct version. The issue here is that IIRC buck Expected behavior 's output should match the version rerefenced in the build file. Notify maintainers
I did try to investigate by bumping buck to its latest release that should be Python3 compatible but didn't get very far as I am unfamiliar with the build system. But maybe the patch helps With this I encountered a failure at the end of the build
buck now generates a hash for build outputs

Discussion:
<del> { lib, stdenv, fetchFromGitHub, jdk, ant, python2, python2Packages, watchman, bash, makeWrapper }: </del> <ins> { lib, stdenv, fetchFromGitHub, jdk11, ant, python3, watchman, bash, makeWrapper }: </ins> stdenv.mkDerivation rec { pname = "buck"; <del> version = "2019.10.17.01"; </del> <ins> version = "2021.01.12.01"; </ins> src = fetchFromGitHub { owner = "facebook"; repo = pname; rev = "v${version}"; <del> sha256 = "1irgp8yq1z11bq3b83yxvj35wqqq7y7b8q4d4y0hc05ac19ja0vj"; </del> <ins> sha256 = "sha256-NFiMQ+cG93R10LlkfUMzZ4TnV0uO5G+8S5TiMI6hU5o="; </ins> }; patches = [ ./pex-mtime.patch ];

grep -l -r '/bin/bash' --null | xargs -0 sed -i -e "s!/bin/bash!${bash}/bin/bash!g" ''; <del> buildInputs = [ jdk ant python2 watchman python2Packages.pywatchman ]; nativeBuildInputs = [ makeWrapper ]; </del> <ins> nativeBuildInputs = [ makeWrapper python3 jdk11 ant watchman ]; </ins> buildPhase = '' <ins> # Set correct version, see https://github.com/facebook/buck/issues/2607 echo v${version} > .buckrelease </ins> ant PYTHONDONTWRITEBYTECODE=true ./bin/buck build -c buck.release_version=${version} buck ''; installPhase = '' <del> install -D -m755 buck-out/gen/programs/buck.pex $out/bin/buck </del> <ins> install -D -m755 buck-out/gen/*/programs/buck.pex $out/bin/buck </ins> wrapProgram $out/bin/buck  <del> --prefix PYTHONPATH : $PYTHONPATH  --prefix PATH : "${lib.makeBinPath [jdk watchman]}" </del> <ins> --prefix PATH : "${lib.makeBinPath [ jdk11 watchman python3 ]}" </ins> ''; meta = with lib; {

wxGTK = wxGTK30; }; <del> buck = callPackage ../development/tools/build-managers/buck { jdk = jdk8; # TODO: remove override https://github.com/NixOS/nixpkgs/pull/89731 }; </del> <ins> buck = callPackage ../development/tools/build-managers/buck { }; </ins> buildkite-agent = buildkite-agent3; buildkite-agent2 = throw "pkgs.buildkite-agent2 has been discontinued. Please use pkgs.buildkite-agent (v3.x)";
Change:
Project description Metadata homepage URL: source URL: license: idk, its not obvious and im not a lawyer platforms: unix/linux?

Discussion:
<ins> { lib , fetchFromGitHub , mkDerivation , breeze-icons , breeze-qt5 , cmake , extra-cmake-modules , kcodecs , kconfig , kcoreaddons , kfilemetadata , ki18n , kiconthemes , kio , kio-extras , kirigami2 , kxmlgui , mpv , pkg-config , qqc2-desktop-style , qtbase , qtquickcontrols2 , qtwayland , youtube-dl }: mkDerivation rec { pname = "haruna"; version = "0.6.1"; src = fetchFromGitHub { owner = "g-fb"; repo = "haruna"; rev = version; sha256 = "sha256-8MauKmvQUwzq4Ssmm6g7/y6ADkye+eg/zyR3v/Wu848="; }; buildInputs = [ breeze-icons breeze-qt5 kcodecs kconfig kcoreaddons kfilemetadata ki18n kiconthemes kio kio-extras kirigami2 kxmlgui mpv qqc2-desktop-style qtbase qtquickcontrols2 qtwayland youtube-dl ]; nativeBuildInputs = [ cmake extra-cmake-modules pkg-config ]; meta = with lib; { homepage = "https://github.com/g-fb/haruna"; description = "Open source video player built with Qt/QML and libmpv"; license = with licenses; [ bsd3 cc-by-40 gpl3Plus wtfpl ]; maintainers = with maintainers; [ jojosch ]; }; } </ins>

gspeech = callPackage ../applications/audio/gspeech { }; <ins> haruna = libsForQt5.callPackage ../applications/video/haruna { }; </ins> icesl = callPackage ../applications/misc/icesl { }; keepassx = callPackage ../applications/misc/keepassx { };
Change:
<!-- 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: pythonPackages.pydantic <!-- 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.8 desired version: 1.8.1 <!-- 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.

Discussion:
buildPythonPackage rec { pname = "pydantic"; <del> version = "1.8"; </del> <ins> version = "1.8.1"; </ins> disabled = pythonOlder "3.7"; src = fetchFromGitHub { owner = "samuelcolvin"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-+HfnM/IrFlUyQJdiOYyaJUNenh8dLtd8CUJWSbn6hwQ="; </del> <ins> sha256 = "1zvcmx3927fgx37gdhi8g8igvrkri1v78rn3118p4wssqhgfwa6n"; </ins> }; propagatedBuildInputs = [
Change:
Describe the bug the build of gupnp-igd seem to be flaky. i have seen the build fail now for the second time in a few days, but when i try again, it works the issue seem to be a TIMEOUT. To Reproduce Steps to reproduce the behavior: that heppened in a system rebuild where many things are build and the system is under load when i build just the one package, it works Expected behavior build should always succeed Additional context build from staging at Notify maintainers cc who updated it last Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I've not run into this, but I don't love flaky tests. Since this passes as long as the system isn't under load... I suppose the best way is to disable the test? Because increasing the timeout doesn't seem like a good long-term fix.
If (for example) the test takes 25-35 seconds, and the timeout is 30 seconds, increasing the timeout to 300 seconds would be a perfectly reasonable long-term fix IMO. Why wouldn't it be? TImeouts are there to catch things that have got stuck, not to test that something is fast, so they don't need to be anywhere close to how long something actually takes, as long as they're short enough that they'll catch stuck processes promptly.
Although, on my 2012 laptop, under load, I can't reproduce this (but have reproduced it on a powerful server). On the laptop it takes 5 seconds normally and 7 under load. So I think maybe it's more likely that it is just getting stuck.
I reported the issue upstream, so they hopefully can fix it and we can enable the check again.
Be my guest, all though in my experience it's basically impossible to put together an actionable bug report for an issue like this.
When they would be able to reproduce it, they can investigate themselves. I have no idea what this is about.

Discussion:
"-Dgtk_doc=true" ]; <del> doCheck = true; </del> <ins> # Seems to get stuck sometimes. # https://github.com/NixOS/nixpkgs/issues/119288 #doCheck = true; </ins> passthru = { updateScript = gnome3.updateScript {