jiebi/CodeConvo huggingface dataset:
Code change:
patches = [ # Not accepted upstream, see https://github.com/gnuradio/gnuradio/pull/5227 ./modtool-newmod-permissions.patch <del> # https://github.com/gnuradio/gnuradio/pull/6808 (fetchpatch { name = "gnuradio-fmt10.1.patch"; url = "https://github.com/gnuradio/gnuradio/commit/9357c17721a27cc0aae3fe809af140c84e492f37.patch"; hash = "sha256-w3b22PTqoORyYQ3RKRG+2htQWbITzQiOdSDyuejUtHQ="; }) </del> ]; passthru = shared.passthru // { # Deps that are potentially overridden and are used inside GR plugins - the same version must

Related discussion:
text: Package name: gnuradio Latest released version: 3.10.8.0 <!-- Search your package here: --- Current version on the unstable channel: 3.10.7.0 Current version on the stable/release channel:3.10.7.0 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Tnx. Update is proposed at
Code change:
# to still support the old standalone toolchains builds. if [ -d $out/libexec/android-sdk/ndk ] && [ ! -d $out/libexec/android-sdk/ndk-bundle ]; then ln -sf $out/libexec/android-sdk/ndk/${package.revision} $out/libexec/android-sdk/ndk-bundle <del> else </del> <ins> elif [ ! -d $out/libexec/android-sdk/ndk-bundle ]; then </ins> echo "The ndk-bundle layout has changed. The nix expressions have to be updated!" exit 1 fi

Related discussion:
text: Starting with it is not possible to build the android sdk with ndk included. I tried varous ndk versions which have different failure messges: fails with fails with Steps to reproduce the behavior: the following with : Dropped into a nix-shell with androidsdk 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.
Code change:
1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/certbot/setup.py b/certbot/setup.py <del> index c1bf914..7456bf2 100644 </del> <ins> index d19327e5e..ac1524793 100644 </ins> --- a/certbot/setup.py +++ b/certbot/setup.py <del> @@ -3,7 +3,6 @@ import os </del> <ins> @@ -1,5 +1,4 @@ import codecs -from distutils.version import StrictVersion import os </ins> import re import sys <del> -from distutils.version import StrictVersion from setuptools import find_packages, setup, __version__ as setuptools_version from setuptools.command.test import test as TestCommand @@ -56,20 +55,8 @@ install_requires = [ </del> <ins> @@ -58,20 +57,8 @@ install_requires = [ </ins> # Add pywin32 on Windows platforms to handle low-level system calls. # This dependency needs to be added using environment markers to avoid its installation on Linux.

Related discussion:
text: Update certbot Current packaged version is 0.39.0, upstream version is 1.2.0.
Fix in
Code change:
environment.systemPackages = [ cfg.package ]; environment.etc = let <del> # generate contents for /etc/systemd/system-${type} from attrset of links and packages hooks = type: links: pkgs.runCommand "system-${type}" { </del> <ins> # generate contents for /etc/systemd/${dir} from attrset of links and packages hooks = dir: links: pkgs.runCommand "${dir}" { </ins> preferLocalBuild = true; packages = cfg.packages; } ''

Related discussion:
text: Unable to use Podman's quadlets feature for a user, since the service unit files are not generated by systemd. Steps to reproduce the behavior: a quadlet file in (say, ) . Systemd says that no unit files were found. Caddy service should have been generated and its status displayed. This issue is caused by not symlinking the provided by the package to . Does not occur at the system level, since is already symlinked to Fix: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Confirmed the quadlet systemd user generator is not found in /etc/systemd. I'm gonna take this one and try to come up with a fix in NixOS module.
Code change:
{ stdenv, fetchFromGitHub, autoreconfHook, pkgconfig, zlib, readline, openssl <del> , libiconv, pcsclite, libassuan, libXt, fetchpatch </del> <ins> , libiconv, pcsclite, libassuan, libXt </ins> , docbook_xsl, libxslt, docbook_xml_dtd_412 , Carbon, PCSC, buildPackages , withApplePCSC ? stdenv.isDarwin

Related discussion:
text: , CVSSv3=5.5 (nixos-20.03, nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.03, nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.03, nixos-20.09, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-20.09: ; nixos-unstable: . Cc
CVE-2020- doesn't seem to have a patch yet. The rest (for all mentioned branches) is going to be addressed in .
Code change:
sortedcontainers, tomlkit, typing-extensions, <del> wheel, </del> }: buildPythonPackage rec {

Related discussion:
text: package lists and as dependencies but upstream uses instead. Steps to reproduce the behavior: dependencies of package it to the dependencies listed by upstream and should not be in the dependencies list, but should n/a <!-- 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]:
That's a bot.
Thank you for the quick turnaround!
Code change:
nativeBuildInputs = [ autoPatchelfHook dpkg <del> makeBinaryWrapper </del> <ins> makeShellWrapper </ins> wrapGAppsHook3 ];

Related discussion:
text: ArmCord's wrapper seems unable to launch under Wayland, always chooses to launch under Steps to reproduce the behavior: sure and are properly set: Armcord: . ... 's on XWayland (as shown by ). I expect it to launch with Wayland instead of XWayland. Custom wrapper: Test case: Log output: <!-- 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]:
probably need makeShellWrapper instead of makeBinaryWrapper in the package
Thanks for jumping on a PR will review this evening.
Code change:
# See https://savannah.gnu.org/bugs/?50339 F77_INTEGER_8_FLAG = if openblas.blas64 then "-fdefault-integer-8" else ""; <del> configureFlags = [ "--enable-readline" "--enable-dl" "--with-blas=openblas" "--with-lapack=openblas" ] ++ stdenv.lib.optional openblas.blas64 "--enable-64" ++ stdenv.lib.optionals stdenv.isDarwin ["--with-x=no"] ; </del> <ins> configureFlags = [ "--enable-readline" "--with-blas=openblas" "--with-lapack=openblas" ] ++ stdenv.lib.optionals openblas.blas64 [ "--enable-64" ] ++ stdenv.lib.optionals stdenv.isDarwin [ "--with-x=no" ] ++ stdenv.lib.optionals enableQt [ "--with-qt=5" ] ++ stdenv.lib.optionals enableJIT [ "--enable-jit" ] ; </ins> # Keep a copy of the octave tests detailed results in the output # derivation, because someone may care

Related discussion:
text: I'm trying to build octave with QT5 and with GUI (of course, when I try to build it with GUI, right?). Unfortunately, after the build: Apply this patch: and then system: host os: multi-user?: sandbox: version: channels(m): nixpkgs:
I just noticed that I do not even get the GUI feature when building octave from nixpkgs (neither nor has a GUI).
Pinging: touched the package recently, is the maintainer of the package.
I’ll try to have a look when I have some time. I’ll let you know what I can achieve.
Here is what the configure script says:
yes, I got that and I fixed it. See for my attempt to build with Qt5 (which succeeds, but starting octave with gui fails - see PR).
Code change:
preInstall = '' function fixRunPath { p=$(patchelf --print-rpath $1) <del> q="$p:${lib.makeLibraryPath [ jsoncpp argtable libmicrohttpd curl ]}:$out/lib" </del> <ins> q="$p:${ lib.makeLibraryPath [ jsoncpp argtable libmicrohttpd curl ] }:$out/lib" </ins> patchelf --set-rpath $q $1 }

Related discussion:
text: Package name: libjson-rpc-cpp Latest released version: 1.3.0 <!-- Search your package here: --- Current version on the unstable channel: 1.3.0 Current version on the stable/release channel: 1.3.0 <!-- 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 no 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]:
Code change:
, lib , qtbase , qtdeclarative <del> , llvmPackages </del> , cups <ins> , llvmPackages # clang-based c++ parser for qdoc and lupdate , withClang ? false </ins> }: qtModule { pname = "qttools"; <del> buildInputs = [ </del> <ins> buildInputs = lib.optionals withClang [ </ins> llvmPackages.libclang llvmPackages.llvm ];

Related discussion:
text: Installing causes large dependencies such as and to be pulled in at run-time Steps to reproduce the behavior: that some of the large dependencies such as are pulled in. I'd expect and to be build-time dependencies, and as such shouldn't be needed at run-time The additional dependencies are being pulled in due to , which itself should be a build dependency. FWIW, declares as a make* dependency Please run and paste the result.
not the maintainer for -qt ( is), but I took a quick look at it nevertheless and it seems that gets to in the invocation for even if it is moved to . Unfortunately I don't know enough about the Qt ecosystem to tell why this is the case.
I think that the issue lies in qttools itself, for some reason after , qttools depends on clang and llvm at runtime This doesn't seem to be the case on and
qttools provides a qt plugin so wrapQtAppsHook will add to ‘QTPLUGINPATH’ automaticallyUnfortunately, the packaging of qttools is not subdivided, all output is almost in one packagethis leads to the addition of unnecessary runtime dependencies. ( Actually even may not be needed is required by and , lupdate seems to be just a optional feature dependency on clangbut is not feasiblewe have to recompile to disable this feature Splitting into multiple packages should be a better solutionqdoc/lupdate are often used to generate documentation/translations, almost no packages runtime depends on them This pr should solve the problem of qalculate-qt but this may cause some packages fail to find lupdate. it‘s not an elegant solution
I think it's easier to add a flag to qttools, and only use that variant for building the docs.
should be , set can prevent qttools from being recognized as a runtime dependency the pull request to disable clang-based c++ parser by default
If that helps, maybe is no longer necessary?
For this issue, yes But not sure if there is a package need qttools (qt plugin ) as runtime dependency
I checked all packages that depends on qttools, and found that most if not all of them have a runtime reference on qttools due to it being in . So this problem is actually widespread, we can have the workaround in for now.
Code change:
stdenv.mkDerivation rec { pname = "remmina"; <del> version = "1.4.13"; </del> <ins> version = "1.4.20"; </ins> src = fetchFromGitLab { owner  = "Remmina"; repo   = "Remmina"; rev    = "v${version}"; <del> sha256 = "sha256-R+RfczAnt5R0YmXt5SmH8gOuWOH0LZ/70pOMDAXJgsE="; </del> <ins> sha256 = "sha256-m3DUaoOD8COxMwCVBTipzCAz3mqIdunEbVPjyjAl9So="; </ins> }; nativeBuildInputs = [ cmake ninja pkg-config wrapGAppsHook ];

Related discussion:
text: <!-- 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: remmina <!-- 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.4.13 desired version: 1.4.20 <!-- 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.
Code change:
<del> { stdenv, lib, buildPackages, automake, autoconf, libtool, which, fetchpatch, openexr }: </del> <ins> { stdenv , buildPackages , cmake , libtool , openexr }: </ins> stdenv.mkDerivation rec { pname = "ilmbase"; <del> version = lib.getVersion openexr; </del> <ins> version = stdenv.lib.getVersion openexr; </ins> # the project no longer provides separate tarballs. We may even want to merge # the ilmbase package into openexr in the future.

Related discussion:
text: Describe the bug build of OpenEXR fails to find -lImath24 To Reproduce Expected behavior Successful build. Screenshots Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: Maintainer information:
Something seems to be mangling the library names incorrectly? The ilmbase package contains: Notice the periods.
cc.
I lack the hardware to debug this. any ideas?
Repro'd on 10.14
seems to indicate that autoconf-based builds are only supported on linux - we may want to switch this to cmake. Building outside of nix via cmake is working fine for me.
can you give a try?
I can confirm this still builds on at least.
appears to fix this for me (macos 10.14). Reopen if it's still a problem for you.
Code change:
<del> export NIX_CC=@out@ </del> addCVars () { if [ -d $1/include ]; then export NIX_CFLAGS_COMPILE+=" ${ccIncludeFlag:--isystem} $1/include"

Related discussion:
text: Optipng crashes with a segmentation fault on current as of . points to the library used to throw/catch exceptions. relevant source: Automatic points to being the first bad revision. However, I don't have enough knowledge of this piece of nix to understand why it causes optipng to fail in the . System: nixos-master Nix version: 1.11.11 Nixpkgs version: Sandboxing enabled: yes CC
Reading into the causing commit's comments made me try which seems to work around the issue. However, I'm hesitant to commit this as a fix without understanding the issue here.
So some packages use the C compiler instead of linker directly to link. Nixpkgs's cc-wrapper is aware of this, for example, with separate and environment variables. Classic make builtin rules however only have , , , and , so then either in a configure script or make itself they seem to default to , but manually specifying breaks this. Manually specifying , however, avoids that pitfall, and, unlike , will also work for cross compilation.
Here's a blurb from optipng's script: If I understand your comment, it looks like optipng's build system is doing precisely what you describe: So when isn't set, it defaults to configuring the such that it uses as the linker, and I suppose the theory is that they depend on behavior available when invoking through e.g. (though I don't know precisely what that may be). It would seem reasonable take the (on a per package basis) approach as a solution. I think this can safely be considered a bug in the upstream packages' build systems.
Probably the use of to pass actual ld flags, e.g. .
I implemented the workaround in . Feel free to reopen this if you don't think the fix to be adequate.
Code change:
<del> export NIX_CC=@out@ </del> addCVars () { if [ -d $1/include ]; then export NIX_CFLAGS_COMPILE+=" ${ccIncludeFlag:--isystem} $1/include"

Related discussion:
text: gcc5 and the dependant gfortran5 packages are failing as of 31 July Failures: ] ] Building either package using or fails. System: (MacOS 10.11.6 and MacOS 10.12.6, both nix-multiuser install) Nix version: (1.11.13) Nixpkgs version: (17.09pre-git) Sandboxing enabled: (relaxed)
has been looking into this but it seems pretty mysterious so far
git-bisect is pretty neat
cc
This is also needed to fix things that depend on gcc
Code change:
<ins> import ./make-test-python.nix ({ pkgs, lib, ... }: { name = "sunshine"; meta = { # test is flaky on aarch64 broken = pkgs.stdenv.isAarch64; maintainers = [ lib.maintainers.devusb ]; }; nodes.sunshine = { config, pkgs, ... }: { imports = [ ./common/x11.nix ]; services.sunshine = { enable = true; openFirewall = true; settings = { capture = "x11"; encoder = "software"; output_name = 0; }; }; environment.systemPackages = with pkgs; [ gxmessage ]; }; nodes.moonlight = { config, pkgs, ... }: { imports = [ ./common/x11.nix ]; environment.systemPackages = with pkgs; [ moonlight-qt ]; }; enableOCR = true; testScript = '' # start the tests, wait for sunshine to be up start_all() sunshine.wait_for_open_port(48010,"localhost") # set the admin username/password, restart sunshine sunshine.execute("sunshine --creds sunshine sunshine") sunshine.systemctl("restart sunshine","root") sunshine.wait_for_open_port(48010,"localhost") # initiate pairing from moonlight moonlight.execute("moonlight pair sunshine --pin 1234 >&2 & disown") moonlight.wait_for_console_text("Executing request") # respond to pairing request from sunshine sunshine.succeed("curl --insecure -u sunshine:sunshine -d '{"pin": "1234"}' https://localhost:47990/api/pin") # close moonlight once pairing complete moonlight.send_key("kp_enter") # put words on the sunshine screen for moonlight to see sunshine.execute("gxmessage 'hello world' -center -font 'sans 75' >&2 & disown") # connect to sunshine from moonlight and look for the words moonlight.execute("moonlight --video-decoder software stream sunshine 'Desktop' >&2 & disown") moonlight.wait_for_text("hello world") ''; }) </ins>

Related discussion:
text: Project description <!-- Describe the project a little: --Sunshine has already been packaged here in nixpkgs: But it doesn't come out of the box just by , according to and and , at least it needs a and maybe . It would be better if we could add a NixOS module for it to make it availale just by sth. like or . CC maintainer Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This has been on my to-do list for ages :) The module itself wouldn't be a huge deal, and I think I have a plan for tests, just need some time to work on it.
I actually started working on this a while ago. My module can create valid and files (i.e. they work when I start sunshine manually) and open the necessary ports, however I couldn't get the systemd service to function properly. If I recall correctly, the issue was related to getting access to the screen. Here is what I have so far, maybe it can help someone:
Thanks I used yours as inspiration and opened for this. It's still a draft -- I need to work on the tests -- but any testing or comments are welcome. I've tested on Plasma 6 + Wayland + AMD and seems to work, have not tested much with Xorg or NVIDIA.
Think it's got all the functionality I had planned -- marked as ready for review.
Code change:
meta = { description = "The Astro language server"; homepage = "https://github.com/withastro/language-tools"; <ins> changelog = "https://github.com/withastro/language-tools/blob/@astrojs/language-server@${finalAttrs.version}/packages/language-server/CHANGELOG.md"; </ins> license = lib.licenses.mit; maintainers = with lib.maintainers; [ pyrox0 ]; mainProgram = "astro-ls";

Related discussion:
text: Package name: astro-language-server Latest released version: 2.14.2 <!-- Search your package here: --- Current version on the unstable channel: 2.10.0 Current version on the stable/release channel: None <!-- 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]:
I'm on it ^^. I've got a working version. Gonna soon open a PR :+1:
Code change:
fetchurl, autoPatchelfHook, dpkg, <del> makeBinaryWrapper, </del> <ins> makeShellWrapper, </ins> wrapGAppsHook3, alsa-lib, at-spi2-atk,

Related discussion:
text: ArmCord's wrapper seems unable to launch under Wayland, always chooses to launch under Steps to reproduce the behavior: sure and are properly set: Armcord: . ... 's on XWayland (as shown by ). I expect it to launch with Wayland instead of XWayland. Custom wrapper: Test case: Log output: <!-- 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]:
probably need makeShellWrapper instead of makeBinaryWrapper in the package
Thanks for jumping on a PR will review this evening.
Code change:
if foundString != testString: raise Exception(f"Read the wrong string from nbd disk. Expected: '{testString}'. Found: '{foundString}'") server.succeed("nbd-client -d /dev/nbd0") <ins> # Server: Successfully connect to the aaa disk server.succeed("nbd-client localhost ${toString listenPort} /dev/nbd0 -name aaa -persist") server.succeed(f"echo '{testString}' | dd of=/dev/nbd0 conv=notrunc") foundString = server.succeed(f"dd status=none if=/aaa.disk count={len(testString)}")[:len(testString)] if foundString != testString: raise Exception(f"Read the wrong string from nbd disk. Expected: '{testString}'. Found: '{foundString}'") server.succeed("nbd-client -d /dev/nbd0") </ins> ''; })

Related discussion:
text: Configuration snippet like this: yield a configuration like: However nbd-server expects section to always appear before export sections, otherwise it complains about not being able to find general section. I'd say this is upstream's fault because this order should not matter, but here we are. section to always appear before export sections. <!-- 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.
This looks like it should be easy to fix. I'll probably get around to it tomorrow morning.
For reference, the error looks like this:
Code change:
{ lib, <ins> stdenv, darwin, </ins> rustPlatform, fetchFromGitHub, pkg-config,

Related discussion:
text: Steps to reproduce the behavior: the package Offending line Seems to me like the darwin framework is missing Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Posted a PR to fix this:
Code change:
let skippedTests = [ "TestDialogs" <ins> "TestVoldialogs" </ins> ]; in '' <del> export USER=$(whoami) export HOME=/home/$USER </del> <ins> export HOME="$(mktemp -d)" </ins> # Disable flaky tests buildFlagsArray+=("-run" "[^(${builtins.concatStringsSep "|" skippedTests})]")

Related discussion:
text: Package name: podman-tui Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 0.18.0 Current version on the stable/release channel: 0.12.0 <!-- 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. --I attempted to update this package myself and create a PR, however, there appears to be a major changes to how this package is built that are outside my ability to address. Attempting to build the package after a , both with and without the changes in , results in the following build log: Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: