jiebi/CodeConvo huggingface dataset:
Change:
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:

Discussion:
exit 1 fi <del> nm -an "$libblas" | cut -f3 -d' ' > symbols </del> <ins> $NM -an "$libblas" | cut -f3 -d' ' > symbols </ins> for symbol in ${toString blasFortranSymbols}; do grep "^$symbol_$" symbols || { echo "$symbol" was not found in "$libblas"; exit 1; } done

wrap ${targetPrefix}gfortran $wrapper $ccPath/${targetPrefix}gfortran ln -sv ${targetPrefix}gfortran $out/bin/${targetPrefix}g77 ln -sv ${targetPrefix}gfortran $out/bin/${targetPrefix}f77 <ins> export named_fc=${targetPrefix}gfortran </ins> '' + optionalString cc.langJava or false ''

setupHooks = [ ../setup-hooks/role.bash <del> ./setup-hook.sh ]; </del> <ins> ] ++ stdenv.lib.optional (cc.langC or true) ./setup-hook.sh ++ stdenv.lib.optional (cc.langFortran or false) ./fortran-hook.sh; </ins> postFixup = ''

<ins> getTargetRole getTargetRoleWrapper export FC${role_post}=@named_fc@ # If unset, assume the default hardening flags. # These are different for fortran. : ${NIX_HARDENING_ENABLE="stackprotector pic strictoverflow relro bindnow"} export NIX_HARDENING_ENABLE unset -v role_post </ins>

]; 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 '' + ''
Change:
Describe the bug The package that there was a directory in go's tools repo. Unfortunately, this directory was removed on commit  Not sure when the binary stopped being shipped in nixpkgs. To Reproduce Steps to reproduce the behavior: latest version of the the directory of the output from the derivation and assert the command is no longer there /a Expected behavior The gopls command should be available, it's a crucial binary, as it is used for lsp support Notify maintainers Metadata Please run and paste the result. Maintainer information:
is now available in package. This was changed in
Uhm, silly me, didn't check there was an independent package now. Would you say it is a good idea to update the referenced comment in this ticket? I can volunteer to update the comment.
Yes, I think so. Let's add a reference to this issue as well.
Created the PR: Apologies for the delay

Discussion:
sha256 = "0a8c7j4w784w441j3j3bh640vy1g6g214641qv485wyi0xj49anf"; }; <del> # Build of golang.org/x/tools/gopls fails with: #   can't load package: package golang.org/x/tools/gopls: unknown import path "golang.org/x/tools/gopls": cannot find module providing package golang.org/x/tools/gopls # That is most probably caused by golang.org/x/tools/gopls containing a separate Go module. # In order to fix this, we simply remove the module. # Note that build of golang.org/x/tools/cmd/gopls provides identical binary as golang.org/x/tools/gopls. # See https://github.com/NixOS/nixpkgs/pull/64335. </del> <ins> # The gopls folder contains a Go submodule which causes a build failure. # Given that, we can't have the gopls binary be part of the gotools # derivation. # # The attribute "gopls" provides the gopls binary. # # Related # # * https://github.com/NixOS/nixpkgs/pull/85868 # * https://github.com/NixOS/nixpkgs/issues/88716 </ins> postPatch = '' rm -rf gopls '';
Change:
OpenTTD as it is currently packaged does not support the XDG base directory specification. According to OpenTTD can support it if libxdg-basedir is available. I've tested this locally and indeed it works if I add libxdg_basedir to the buildInputs. But, adding this would be surprising behaviour to current users, since OpenTTD may suddenly start looking in a different place for its mods and saves and such. Is this something we'd want to change in nixpkgs, or maybe hide it behind a flag? I can open a PR for it but I'd also be happy leaving it in my local config.
It's a game, so it's unlikely that people will mind a change. cc

Discussion:
<del> { stdenv, fetchurl, fetchzip, pkgconfig, SDL2, libpng, zlib, xz, freetype, fontconfig </del> <ins> { stdenv, fetchurl, fetchzip, pkgconfig, SDL2, libpng, zlib, xz, freetype, fontconfig, libxdg_basedir </ins> , withOpenGFX ? true, withOpenSFX ? true, withOpenMSX ? true , withFluidSynth ? true, audioDriver ? "alsa", fluidsynth, soundfont-fluid, procps , writeScriptBin, makeWrapper, runtimeShell

}; nativeBuildInputs = [ pkgconfig makeWrapper ]; <del> buildInputs = [ SDL2 libpng xz zlib freetype fontconfig ] </del> <ins> buildInputs = [ SDL2 libpng xz zlib freetype fontconfig libxdg_basedir ] </ins> ++ stdenv.lib.optionals withFluidSynth [ fluidsynth soundfont-fluid ]; prefixKey = "--prefix-dir=";
Change:
Describe the bug Running fails with To Reproduce Extra info On of that script scopeoCmd isn't called correctly. Seems like introduced the problem in this PR

Discussion:
hashType=$NIX_HASH_ALGO hashFormat=$hashFormat format=nix <del> skopeoCmd="skopeo --insecure-policy --tmpdir=$TMPDIR" </del> usage(){ echo  >&2 "syntax: nix-prefetch-docker [options] [IMAGE_NAME [IMAGE_TAG|IMAGE_DIGEST]]

imageTag="latest" fi <del> "$skopeoCmd" inspect "docker://$imageName:$imageTag" | jq '.Digest' -r </del> <ins> skopeo --insecure-policy --tmpdir=$TMPDIR inspect "docker://$imageName:$imageTag" | jq '.Digest' -r </ins> } get_name() {

tmpFile="$tmpPath/$(get_name $finalImageName $finalImageTag)" if test -z "$QUIET"; then <del> "$skopeoCmd" --override-os ${os} --override-arch ${arch} copy "$sourceUrl" "docker-archive://$tmpFile:$finalImageName:$finalImageTag" </del> <ins> skopeo --insecure-policy --tmpdir=$TMPDIR --override-os ${os} --override-arch ${arch} copy "$sourceUrl" "docker-archive://$tmpFile:$finalImageName:$finalImageTag" </ins> else <del> "$skopeoCmd" --override-os ${os} --override-arch ${arch} copy "$sourceUrl" "docker-archive://$tmpFile:$finalImageName:$finalImageTag" > /dev/null </del> <ins> skopeo --insecure-policy --tmpdir=$TMPDIR --override-os ${os} --override-arch ${arch} copy "$sourceUrl" "docker-archive://$tmpFile:$finalImageName:$finalImageTag" > /dev/null </ins> fi # Compute the hash.
Change:
Describe the bug program crash when clicking button To Reproduce Steps to reproduce the behavior: a database in keepassxc settings, secret service integration freedesktop integration edit database settings Expected behavior dialog open or something, no crash Screenshots ! Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
This is an . Workaround: Between steps 3 and 4, click "OK" and re-enter settings. You should then be able to edit the database settings.

Discussion:
, qttools , darwin <ins> , asciidoctor </ins> , curl , glibcLocales , libXi

stdenv.mkDerivation rec { pname = "keepassxc"; <del> version = "2.5.4"; </del> <ins> version = "2.6.0"; </ins> src = fetchFromGitHub { owner = "keepassxreboot"; repo = "keepassxc"; rev = version; <del> sha256 = "1xih9q1pxszalc0l29fmjxwn1vrrrrbnhc8gmi8brw5sclhbs6bh"; </del> <ins> sha256 = "0yi6kxnsrqirjn6hxhwym2krzf86qxf3kc6bfpkmiaggnd2kqpkp"; </ins> }; NIX_CFLAGS_COMPILE = stdenv.lib.optionalString stdenv.cc.isClang [

patches = [ ./darwin.patch <del> # use wl-copy on Wayland - can be dropped with the next version update (fetchpatch { url = "https://github.com/keepassxreboot/keepassxc/commit/6128e5d58294f26411160f44da91087ebe7f4b07.patch"; sha256 = "16q0h7kijqjdbskmk4ar6p3g8vcxr0bq1zrlq2bk16pk10nv4bh1"; }) </del> ]; cmakeFlags = [

nativeBuildInputs = [ cmake wrapQtAppsHook qttools ]; buildInputs = [ <ins> asciidoctor </ins> curl glibcLocales libXi
Change:
Describe the bug references because is in the inputs and it patches the samples at : To Reproduce Expected behavior No reference. Additional context I'm up to patchelf binaries that we ship, but: 1) depends on intel-media-sdk and users of it shouldn't get gcc in their closure for this. 2) We don't have even to ship the samples to everyone. Maybe split the outputs? Notify maintainers . Metadata Maintainer information:
I did a quick attempt at splitting the output, but it didn't work out very well. I'll have a further look this weekend.
Interesting... it also happens when is not in the inputs. As an alternative approach to split the outputs. This seems to work: But I wonder: Why do we ship samples? Perhaps:
BTW Why did you use ? It seems the samples are build from source... I think you've meant to them? That would have had to be done with: But this also fails with the same error: Which is super . Anyway I think we should leave off the samples:
I vaguely remember that there were linking problems with the sample binaries, mostly likely due to not being put in rpath.
I've had a further look into this problem, and it looks like changing the datadir from to would solve the problem with rpath, making patchelf unnecessary. Come to think of it, I think the samples belong to in the first place, but it's only a minor annoyance we can easily change. As of why I didn't exclude the samples, I'm rather hesitant at removing features unless there's a good reason for doing so. I'm all for removing it if it does turn out to cause problems, but I'd prefer taking a different approach if I can.
Actually, it looks like there no longer is a problem with rpath, so we can safely remove without changing the build flags at all.
Correction, there still were rpath problems present and changing datadir to didn't solve the problem. There are ways to deal with this besides using , but maybe you're right and it's easier to just remove the samples at this point. For reference, I did some quick search to see what other distros are doing: Debian: packages the samples in a separate package [1] Fedora: disables the samples all together [2] It's divided, but at least we're not alone if we do remove it. [1]: [2]:

Discussion:
<del> { stdenv, fetchurl, autoPatchelfHook, cmake, pkgconfig, libdrm, libpciaccess , libva , libX11, libXau, libXdmcp, libpthreadstubs }: </del> <ins> { stdenv, fetchurl, cmake, pkgconfig, gtest, libdrm, libpciaccess, libva, libX11 , libXau, libXdmcp, libpthreadstubs }: </ins> stdenv.mkDerivation rec { pname = "intel-media-sdk";

sha256 = "1p13b4abslq31pbgqf0bzs2ixns85yfdsm94326h2vcg0q7hqc24"; }; <del> # patchelf is needed for binaries in $out/share/samples nativeBuildInputs = [ autoPatchelfHook cmake pkgconfig ]; </del> <ins> nativeBuildInputs = [ cmake pkgconfig ]; </ins> buildInputs = [ libdrm libva libpciaccess libX11 libXau libXdmcp libpthreadstubs ]; <ins> checkInputs = [ gtest ]; cmakeFlags = [ "-DBUILD_SAMPLES=OFF" "-DBUILD_TESTS=${if doCheck then "ON" else "OFF"}" "-DUSE_SYSTEM_GTEST=ON" ]; doCheck = true; </ins> enableParallelBuild = true; meta = with stdenv.lib; {
Change:
Describe the bug references . I can't figure out yet why. To Reproduce Expected behavior No gcc reference. Additional context is a dependency of which is a common dependency for many applications. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(doron): nixpkgs: Maintainer information:
GitHub doesn't automatically close issues with PRs that had ?
It does usually, not sure what went wrong here.

Discussion:
<del> { stdenv, fetchFromBitbucket, cmake }: </del> <ins> { stdenv, fetchFromBitbucket, cmake, removeReferencesTo }: </ins> let version = "0.6.3"; in stdenv.mkDerivation {

}; buildInputs = [ cmake ]; <ins> nativeBuildInputs = [ removeReferencesTo ]; # It used to reference it, in the past, but thanks to the postFixup hook, now # it doesn't. disallowedReferences = [ stdenv.cc.cc ]; postFixup = stdenv.lib.optionalString stdenv.isLinux '' remove-references-to -t ${stdenv.cc.cc} "$(readlink -f $out/lib/libgme.so)" ''; </ins> }
Change:
Describe the bug clones each submodule in sequence instead of in parallel, which is unnecessarily slow for repos that have a lot of submodules (such as which has 64 direct submodules). At first I thought this was because git's setting defaults to , but it turns out doesn't even use that, it instead recursively clones the submodules by hand. it looks like you this 10 years ago; is there any reason we can't just use today? I don't know why it doesn't just use git's built-in submodule handling, doing so would make fixing this trivial. Parallelizing the manual clone loop seems a lot more complicated (especially because of the problem of mixed output). To Reproduce Steps to reproduce the behavior: from scratch. (Edit: was recently updated to not use submodules anymore. This can be reproduced using an older version) Expected behavior It should clone the repo in a reasonable amount of time. Notify maintainers Last few changes to were and Metadata system: host os: multi-user?: sandbox: version: channels(lily): nixpkgs: Maintainer information:
I marked this as stale due to inactivity. &rarr;
See
Simplified in

Discussion:
# Update submodules init_submodules(){ <del> # Add urls into .git/config file clean_git submodule init # list submodule directories and their hashes git submodule status | while read -r l; do local hash local dir local name local url # checkout each submodule hash=$(echo "$l" | awk '{print $1}' | tr -d '-') dir=$(echo "$l" | sed -n 's/^.[0-9a-f]+ (.*[^)]*)( (.*))?$/1/p') name=$( git config -f .gitmodules --get-regexp submodule..*.path | sed -n "s,^(.*).path $dir$,1,p") url=$(git config --get "${name}.url") clone "$dir" "$url" "$hash" "" done </del> <ins> clean_git submodule update --init --recursive -j $NIX_BUILD_CORES </ins> } clone(){
Change:
Describe the bug If I open a project using unityhub it crashes soon after briefly displaying a loading screen. To Reproduce Steps to reproduce the behavior: any Unity version (I tried multiple 2019.3.* versions, 2018.4 and 2020.1b) a project (doesn't matter which template) or open an existing project Expected behavior Running Unity Logs (after creating/opening a project from the 3d template) (relevant parts) The logs from the 3d template based project also don't say very much interesting. (the only log in of the project) Additional context It's kinda weird I had Unity running when I installed unityhub the first time (around 1 1/2 months ago) But suddenly (a few days after that) it started crashing, soon after opening a project (I guess it was a ) . I think I invested now multiple hours to debug this issue, but I'm at the end of my abilities (as I'm also rather new to NixOS) since the error logs are rather sparse regarding this issue. I deleted all kinds of side-effects of Unity Hub and Unity. At least I think that I deleted all of them: I searched for all kinds of unity variations in the home folder, so I hope I was thorough enough. Fortunately I got it working with flatpak, but there I have now other issues (they have no git included which is needed for some UPM packages) But the flatpak (in which it's working) might be interesting for context: (I've ommitted most of the log, as it was very long, and in my opinion not relevant for this issue) Btw. while debugging I tried the recently new released Unity Hub version (2.3.2) with local nixpkgs. I already uploaded it to with the hash: I also think that should be in the as well (as mentioned for flatpak) 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
Yes, I experience the same issues. Worth noting, I tried manually running Unity executable installed by Unity Hub and for latest LTS this worked: But it's still pretty unusable because with this approach UI is too buggy (for example dialog windows are closing themselves straight after opening, so there's no way to do many configuration things).

Discussion:
libpqxx gtk3 libsecret lsb-release openssl nodejs ncurses5 libX11 libXcursor libXdamage libXfixes libXrender libXi <del> libXcomposite libXext libXrandr libXtst libSM libICE libxcb ]); </del> <ins> libXcomposite libXext libXrandr libXtst libSM libICE libxcb libselinux pciutils libpulseaudio ]); </ins> profile = '' export XDG_DATA_DIRS=${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}:${gtk3}/share/gsettings-schemas/${gtk3.name}:$XDG_DATA_DIRS
Change:
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.

Discussion:
exit 1 fi <del> nm -an "$libblas" | cut -f3 -d' ' > symbols </del> <ins> $NM -an "$libblas" | cut -f3 -d' ' > symbols </ins> for symbol in ${toString blasFortranSymbols}; do grep "^$symbol_$" symbols || { echo "$symbol" was not found in "$libblas"; exit 1; } done

wrap ${targetPrefix}gfortran $wrapper $ccPath/${targetPrefix}gfortran ln -sv ${targetPrefix}gfortran $out/bin/${targetPrefix}g77 ln -sv ${targetPrefix}gfortran $out/bin/${targetPrefix}f77 <ins> export named_fc=${targetPrefix}gfortran </ins> '' + optionalString cc.langJava or false ''

setupHooks = [ ../setup-hooks/role.bash <del> ./setup-hook.sh ]; </del> <ins> ] ++ stdenv.lib.optional (cc.langC or true) ./setup-hook.sh ++ stdenv.lib.optional (cc.langFortran or false) ./fortran-hook.sh; </ins> postFixup = ''

<ins> getTargetRole getTargetRoleWrapper export FC${role_post}=@named_fc@ # If unset, assume the default hardening flags. # These are different for fortran. : ${NIX_HARDENING_ENABLE="stackprotector pic strictoverflow relro bindnow"} export NIX_HARDENING_ENABLE unset -v role_post </ins>

]; 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 '' + ''
Change:
After PR phpExtensions.mysqlnd not supported compression. Checked with
cc
Not supported gzip compression and OpenSSL signatures on phar package before update

Discussion:
inherit configureFlags internalDeps buildInputs zendExtension doCheck; <ins> prePatch = "pushd ../.."; postPatch = "popd"; </ins> preConfigure = '' nullglobRestore=$(shopt -p nullglob) shopt -u nullglob   # To make ?-globbing work

# The configure script doesn't correctly add library link # flags, so we add them to the variable used by the Makefile # when linking. <del> MYSQLND_SHARED_LIBADD = "-lssl -lcrypto -lz"; </del> <ins> MYSQLND_SHARED_LIBADD = "-lssl -lcrypto"; </ins> # The configure script builds a config.h which is never # included. Let's include it in the main header file # included by all .c-files. patches = [ (pkgs.writeText "mysqlnd_config.patch" '' <del> --- a/mysqlnd.h +++ b/mysqlnd.h </del> <ins> --- a/ext/mysqlnd/mysqlnd.h +++ b/ext/mysqlnd/mysqlnd.h </ins> @@ -1,3 +1,6 @@ +#ifdef HAVE_CONFIG_H +#include "config.h"

+----------------------------------------------------------------------+ | Copyright (c) The PHP Group                                          | '') <ins> (pkgs.writeText "mysqlnd_fix_compression.patch" '' --- a/ext/mysqlnd/mysqlnd.h +++ b/ext/mysqlnd/mysqlnd.h @@ -48,7 +48,7 @@ #define MYSQLND_DBG_ENABLED 0 #endif -#if defined(MYSQLND_COMPRESSION_WANTED) && defined(HAVE_ZLIB) +#if defined(MYSQLND_COMPRESSION_WANTED) #define MYSQLND_COMPRESSION_ENABLED 1 #endif '') </ins> ]; postPhpize = lib.optionalString (lib.versionOlder php.version "7.4") '' substituteInPlace configure --replace '$OPENSSL_LIBDIR' '${openssl}/lib' 

# included after the ifdef... patches = lib.optional (lib.versionOlder php.version "7.4") [ (pkgs.writeText "zend_file_cache_config.patch" '' <del> --- a/zend_file_cache.c +++ b/zend_file_cache.c </del> <ins> --- a/ext/opcache/zend_file_cache.c +++ b/ext/opcache/zend_file_cache.c </ins> @@ -27,9 +27,9 @@ #include "ext/standard/md5.h" #endif
Change:
Describe the bug After the PR is merged, as , fails to evaluate on . This is quite annoying because is a dependency of , which makes a sizable chunk of fail to evaluate on . I encountered this issue when trying to build . To Reproduce Steps to reproduce the behavior: Expected behavior , therefore to evaluate and run successfully on . cc
I believe should change the error message, but not fix the problem. Now the trace should go like hidapi -systemd, instead of hidapi -libusb -systemd. I don't really know where the infinite recursion comes from as that doesn't happen with nixos-19.09, however even if that didn't happen it wouldn't matter because systemd doesn't work with musl. If you want to fix this you'd have to look into getting the systemd dependency out of the hidapi nix expression. I'm not really sure why it's there in the first place, glancing at the hidapi , it seems like it depends on udev, which depends on util-linux which depends on systemd, but not on systemd directly and util-linux can be build without systemd. The utillinux nix expression already accounts for that possibility, you'd just have to make it actually do that for pkgsMusl. You could take the libusb nix expression as a template on how to achieve this. Disclaimer: I have virtually no experience with these low-level things, so I may be wrong.

Discussion:
NIX_LDFLAGS = stdenv.lib.optionalString stdenv.isLinux "-lgcc_s"; <del> preFixup = stdenv.lib.optionalString stdenv.isLinux '' </del> <ins> configureFlags = stdenv.lib.optional (!enableSystemd) "--disable-udev"; preFixup = stdenv.lib.optionalString enableSystemd '' </ins> sed 's,-ludev,-L${stdenv.lib.getLib systemd}/lib -ludev,' -i $out/lib/libusb-1.0.la '';

, withGssapiPatches ? false , kerberos , libfido2 <del> , withFIDO ? stdenv.hostPlatform.isUnix </del> <ins> , withFIDO ? stdenv.hostPlatform.isUnix && !stdenv.hostPlatform.isMusl </ins> , linkOpenssl? true }: