jiebi/CodeConvo huggingface dataset:
Change:
Describe the bug Despite the derivation adding the flag '--enable-ssl' to the ./configure invocation dillo is not able to access site served via https:// To Reproduce Steps to reproduce the behavior: dillo to access Expected behavior Either dillo should not be compiled with the --enable-ssl flag or dillo should be able to access sites served with https Additional context This seems to be a common issue with dillo. Applying provided by the Debian packaging team solves this issue. My attempt to fix this. Metadata Maintainer information:
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 .
This is old! Unfortunately I was not pinged on that time, however I have fixed it today.

Discussion:
<del> { lib, stdenv, fetchurl </del> <ins> { lib , stdenv , fetchhg , autoreconfHook </ins> , fltk <ins> , libXcursor , libXi , libXinerama , libjpeg , libpng , mbedtls </ins> , openssl <del> , libjpeg, libpng </del> , perl <del> , libXcursor, libXi, libXinerama }: </del> <ins> , pkg-config , which }: </ins> <del> stdenv.mkDerivation rec { version = "3.0.5"; </del> <ins> stdenv.mkDerivation { </ins> pname = "dillo"; <ins> version = "unstable-2021-02-09"; </ins> <del> src = fetchurl { url = "https://www.dillo.org/download/${pname}-${version}.tar.bz2"; sha256 = "12ql8n1lypv3k5zqgwjxlw1md90ixz3ag6j1gghfnhjq3inf26yv"; </del> <ins> src = fetchhg { url = "https://hg.sr.ht/~seirdy/dillo-mirror"; rev = "67b70f024568b505633524be61fcfbde5337849f"; sha256 = "sha256-lbn5u9oEL0zt9yBhznBS9Dz9/6kSwRDJeNXKEojty1g="; </ins> }; <del> buildInputs = with lib; [ perl fltk openssl libjpeg libpng libXcursor libXi libXinerama ]; </del> <ins> nativeBuildInputs = [ autoreconfHook pkg-config which ]; buildInputs = [ fltk libXcursor libXi libXinerama libjpeg libpng mbedtls openssl perl ]; </ins> # Workaround build failure on -fno-common toolchains: #   ld: main.o:/build/dillo-3.0.5/dpid/dpid.h:64: multiple definition of `sock_set'; #     dpid.o:/build/dillo-3.0.5/dpid/dpid.h:64: first defined here NIX_CFLAGS_COMPILE = "-fcommon"; <del> configureFlags = [ "--enable-ssl" ]; </del> <ins> configureFlags = [ "--enable-ssl=yes" ]; </ins> meta = with lib; { <del> homepage = "https://www.dillo.org/"; </del> <ins> homepage = "https://hg.sr.ht/~seirdy/dillo-mirror"; </ins> description = "A fast graphical web browser with a small footprint"; longDescription = '' Dillo is a small, fast web browser, tailored for older machines. ''; maintainers = [ maintainers.AndersonTorres ]; platforms = platforms.linux; <del> license = licenses.gpl3; </del> <ins> license = licenses.gpl3Plus; </ins> }; }
Change:
, CVSSv3=7.5 (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
See also:
Unstable/master: PR ; 19.09: (staging ATM, but should get into channel within days).

Discussion:
# Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}
Change:
, CVSSv3=6.4 (nixos-19.09) CVSSv3=5.3 (nixos-19.09) CVSSv3=4.3 (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
These CVEs seem to only affect Jenkins Git Plugin. But here is a real git vulnerability found in that version: Related PRs:
CVE-2020-5260 is fixed on 19.09, 20.03 and staging-next (soonish to master, )

Discussion:
# Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}
Change:
, CVSSv3=7.5 (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
(affects only PHP 7.4)

Discussion:
in { php72 = generic { <del> version = "7.2.25"; sha256 = "17kb7b3wpdmdhnlv23qc0vax0lp2gr1v7dxwdgs8g78gxnqkdcvw"; </del> <ins> version = "7.2.26"; sha256 = "0yw49v3rk3cd0fb4gsli74pgd4qrykhn9c37dyfr3zsprzp8cvgk"; </ins> # https://bugs.php.net/bug.php?id=76826 extraPatches = optional stdenv.isDarwin ./php72-darwin-isfinite.patch; }; php73 = generic { <del> version = "7.3.12"; sha256 = "0fccmnrwwyy5zvhj8wbyqqlyqr7pr5v4pfiqriw0ahciz4lv05yk"; </del> <ins> version = "7.3.13"; sha256 = "1g376b9caw21mw8738z354llbzb3shzgc60m7naw7wql5038jysw"; </ins> # https://bugs.php.net/bug.php?id=76826 extraPatches = optional stdenv.isDarwin ./php73-darwin-isfinite.patch; }; php74 = generic { <del> version = "7.4.0"; sha256 = "1h01bahvcm9kgm5jqhm2j9k9d4q4rpfkkpqk00c47rirdblnn85z"; </del> <ins> version = "7.4.1"; sha256 = "0klfwhm2935ariwzqdri1fwh4a0vbrk3jis53qzi18isp3qa073b"; </ins> }; }
Change:
The release and git versions show gpl2+. It should be Affero GPL v3 or later. GNUnet is free software released under the GNU Affero General Public License (v3 or later).

Discussion:
''; homepage = https://gnunet.org/; <del> license = licenses.gpl2Plus; </del> <ins> license = licenses.agpl3Plus; </ins> maintainers = with maintainers; [ vrthra ]; platforms = platforms.gnu ++ platforms.linux; };

''; */ <del> meta = { </del> <ins> meta = with stdenv.lib; { </ins> description = "GNUnet, GNU's decentralized anonymous and censorship-resistant P2P framework"; longDescription = ''

homepage = https://gnunet.org/; <del> license = stdenv.lib.licenses.gpl2Plus; </del> <ins> license = licenses.agpl3Plus; </ins> maintainers = with stdenv.lib.maintainers; [ ]; <del> platforms = stdenv.lib.platforms.gnu ++ stdenv.lib.platforms.linux; </del> <ins> platforms = platforms.gnu ++ platforms.linux; </ins> }; }
Change:
Describe the bug Typora have released version 0.9.80 To Reproduce Steps to reproduce the behavior: -env -i typora old version compared to the latest version in their website :( Expected behavior The latest version should be installed Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
Can do :+1:
Hey, I just noticed that the current version 0.9.73 is broken (download link at least), I'll update it to 0.9.9.33.2. Edit: I just noticed that the url using the version is now broken all versions. We should replace the deb package: ${version} by Do you have a better idea?

Discussion:
, lib , fetchurl , makeWrapper <del> , electron_5 </del> <ins> , electron_8 </ins> , dpkg , gtk3 , glib

stdenv.mkDerivation rec { pname = "typora"; <del> version = "0.9.73"; </del> <ins> version = "0.9.89"; </ins> src = fetchurl { url = "https://www.typora.io/linux/typora_${version}_amd64.deb"; <del> sha256 = "1fgcb4bx5pw8ah5j30d38gw7qi1cmqarfhvgdns9f2n0d57bvvw3"; </del> <ins> sha256 = "0gk8j13z1ymad34zzcy4vqwyjgd5khgyw5xjj9rbzm5v537kqmx6"; </ins> }; nativeBuildInputs = [

gtk3 ]; <del> unpackPhase = "dpkg-deb -x $src ."; </del> <ins> # The deb contains setuid permission on `chrome-sandbox`, which will actually not get installed. unpackPhase = "dpkg-deb --fsys-tarfile $src | tar -x --no-same-permissions --no-same-owner"; </ins> dontWrapGApps = true;

''; postFixup = '' <del> makeWrapper ${electron_5}/bin/electron $out/bin/typora  </del> <ins> makeWrapper ${electron_8}/bin/electron $out/bin/typora  </ins> --add-flags $out/share/typora  "''${gappsWrapperArgs[@]}"  ${lib.optionalString withPandoc ''--prefix PATH : "${lib.makeBinPath [ pandoc ]}"''}
Change:
someone has push -f'ed a ghcjs-boot subrepo and the current commit commited to file is no longer buildable. i am submitting a pr with my proposed solution atm

Discussion:
libDir = "share/ghcjs/${ghcArch}-${version}-${ghc.version}/ghcjs"; ghcjsBoot = fetchgit { url = git://github.com/ghcjs/ghcjs-boot.git; <del> rev = "8bf1a2c665d42a66354f17220c7dfb1c8b44c0ea"; # 7.10 branch sha256 = "18bm6sfa9c9kwsmv3lz6j27ng6jl0ck3ifgqbwwa8myfy7fw4il7"; </del> <ins> rev = "ab8765edcb507b8b810e3c324fd5bd5af2b69d8f"; # 7.10 branch sha256 = "63b69a1d131cf3c7088e0f28d14750c81361dcc276fa113ad80dcccf73df5343"; </ins> fetchSubmodules = true; }; shims = fetchgit {
Change:
Describe the bug I think this is another problem: After installing root (I'm using ), when I launch , I got the following error: I managed to find an improper workaround: First I located the installation directory of : Then I manually specify the location of the Python library that comes with : Now can launch properly. To Reproduce Steps to reproduce the behavior: in in terminal Expected behavior It should run without problem. Metadata Please run and paste the result. Maintainer information:
It is worth noting that if I manually source the supplied , can run without problem, and I can import in a Python 3 interpreter. I think a (not the) reasonable approach would be: globally usable, since it really is an utility the Python moduel as-is (not available unless explicitly sourced by user) Arch linux takes the approach above, and they copy the module to global Python library path. But I'm not sure on how to do this sanely in nix. For example, in my overlay, I have Python defined as: But I don't know how to include ---a Python library provided by package---globally.
Alternatively, I can just source in my login shell. Which is actually not too bad.
Yes, you are right about needing to source This is done automatically in our for , so everything works when is used in other nix builds and in nix-shell: nix-env does not run setupHook, so you would need to source it yourself, the way ROOT was intended to be used. In nixpkgs we usually make sure that all of the binaries are wrapped or patched to be able to find their libraries in any environment, so this is considered to be a bug.

Discussion:
<del> { stdenv, fetchurl, cmake, gl2ps, gsl, libX11, libXpm, libXft, libXext , libGLU, libGL, libxml2, lz4, lzma, pcre, pkgconfig, python, xxHash, zlib </del> <ins> { stdenv, fetchurl, makeWrapper, cmake, gl2ps, gsl, libX11, libXpm, libXft , libXext, libGLU, libGL, libxml2, lz4, lzma, pcre, pkgconfig, python, xxHash , zlib </ins> , Cocoa, OpenGL, noSplash ? false }: stdenv.mkDerivation rec {

sha256 = "196ghma6g5a7sqz52wyjkgvmh4hj4vqwppm0zwdypy33hgy8anii"; }; <del> nativeBuildInputs = [ cmake pkgconfig ]; </del> <ins> nativeBuildInputs = [ makeWrapper cmake pkgconfig ]; </ins> buildInputs = [ gl2ps pcre python zlib libxml2 lz4 lzma gsl xxHash ] ++ stdenv.lib.optionals (!stdenv.isDarwin) [ libX11 libXpm libXft libXext libGLU libGL ] ++ stdenv.lib.optionals (stdenv.isDarwin) [ Cocoa OpenGL ]

enableParallelBuilding = true; <ins> postInstall = '' for prog in rootbrowse rootcp rooteventselector rootls rootmkdir rootmv rootprint rootrm rootslimtree; do wrapProgram "$out/bin/$prog"  --prefix PYTHONPATH : "$out/lib" done ''; </ins> setupHook = ./setup-hook.sh; meta = with stdenv.lib; {
Change:
Describe the bug As of now the pyramid package depends on the package which is originally on the section of the package definition: This brings in a big chunk of dependencies that are on the for an unclear advantage. As of now the dependency on brings in also a dependency on making it very difficult to override it for a database applications that uses pyramid. Would it be possible/feasible to duplicate the package building one without all that chunk of doc-only dependencies? Should I propose a PR? Maintainer information:
Maybe a solution could be to just move the "docs" dependencies to the .
extras should not be included by default
cc

Discussion:
{ stdenv , buildPythonPackage , fetchPypi <del> , docutils , virtualenv </del> , webtest , zope_component , hupper

, plaster , plaster-pastedeploy , repoze_lru <del> , repoze_sphinx_autointerface </del> , translationstring , venusian , webob

sha256 = "d80ccb8cfa550139b50801591d4ca8a5575334adb493c402fce2312f55d07d66"; }; <del> checkInputs = [ docutils virtualenv webtest zope_component ]; </del> <ins> checkInputs = [ webtest zope_component ]; </ins> <del> propagatedBuildInputs = [ hupper PasteDeploy plaster plaster-pastedeploy repoze_lru repoze_sphinx_autointerface translationstring venusian webob zope_deprecation zope_interface ]; </del> <ins> propagatedBuildInputs = [ hupper PasteDeploy plaster plaster-pastedeploy repoze_lru translationstring venusian webob zope_deprecation zope_interface ]; </ins> # Failing tests # https://github.com/Pylons/pyramid/issues/1899
Change:
Describe the bug Vagrant no longer works; every operation fails with an error . I bisected this regression to commit “ruby: rubygems 3.0.6 -3.1.2” (). To Reproduce Expected behavior Metadata Maintainer information: cc
I note that the “smoke test” in was not sufficient to catch this problem, although would have. Perhaps would be even better?
Just took a look at this as well (please note that I'm not a ruby developer, so I may be missing something). 3.1.x seems to require bundler now[1] and vendors bundler 2.1.2[2] in version 3.1.2, however ruby 2.6 vendors bundler 1.17, so there's probably some kind of mismatch when using rubygems 3.1.2. Not sure, but would it make sense to add different rubygems versions for different ruby versions? [1] [2]

Discussion:
inherit version; }; } // lib.optionalAttrs withLibvirt (import ./gemset_libvirt.nix)); <ins> # This replaces the gem symlinks with directories, resolving this # error when running vagrant (I have no idea why): # /nix/store/p4hrycs0zaa9x0gsqylbk577ppnryixr-vagrant-2.2.6/lib/ruby/gems/2.6.0/gems/i18n-1.1.1/lib/i18n/config.rb:6:in `<module:I18n>': uninitialized constant I18n::Config (NameError) postBuild = '' for gem in "$out"/lib/ruby/gems/*/gems/*; do cp -a "$gem/" "$gem.new" rm "$gem" mv "$gem.new" "$gem" done ''; </ins> }; in buildRubyGem rec {

''; installCheckPhase = '' <del> if [[ "$("$out/bin/vagrant" --version)" == "Vagrant ${version}" ]]; then echo 'Vagrant smoke check passed' else echo 'Vagrant smoke check failed' return 1 fi </del> <ins> HOME="$(mktemp -d)" $out/bin/vagrant init --output - > /dev/null </ins> ''; # `patchShebangsAuto` patches this one script which is intended to run
Change:
mostly detailed from discorse. Pasting comments below: nix-build -A at-spi2-core '<nixpkgs' (which, say, installs into $directory-for-libatspi/lib) Setting the game’s launch options to LDLIBRARYPATH="LDLIBRARYPATH" %command% However, this doesn’t seem like a permanent or smart fix. How do I improve on that? Is it a fix for the Steam package in nixpkgs? I’d imagine it already includes some well-known .so files in its environment.

Discussion:
# Not formally in runtime but needed by some games at-spi2-atk <ins> at-spi2-core   # CrossCode </ins> gst_all_1.gstreamer gst_all_1.gst-plugins-ugly libdrm
Change:
Describe the bug Supported devices do not show up in piper's GUI. To Reproduce Steps to reproduce the behavior: service - a supported device Expected behavior The device shows up in piper GUI. Screenshots N/A Additional context Running compatible version of piper fixes the issue: 09 currently ships with piper 0.2.903. Metadata Please run and paste the result. Maintainer information:
is merged

Discussion:
# Media support MEDIA_CAMERA_SUPPORT? y MEDIA_RC_SUPPORT? y <ins> MEDIA_USB_SUPPORT y </ins> ${if kernelPlatform ? kernelExtraConfig then kernelPlatform.kernelExtraConfig else ""} ${extraConfig}
Change:
Describe the bug
cc
says the first bad commit is “dhcpcd: 8.1.2 -8.1.4” ().
And on dhcpcd says the first bad commit is rsmarples/dhcpcd “Linux: prefer ms RA times”.
cc
Sent a proposed fix upstream as rsmarples/dhcpcd.
And sent the fix here as .

Discussion:
<del> { stdenv, fetchurl, pkgconfig, udev, runtimeShellPackage, runtimeShell }: </del> <ins> { stdenv, fetchurl, fetchpatch, pkgconfig, udev, runtimeShellPackage, runtimeShell }: </ins> stdenv.mkDerivation rec { # when updating this to >=7, check, see previous reverts:

substituteInPlace hooks/dhcpcd-run-hooks.in --replace /bin/sh ${runtimeShell} ''; <ins> patches = [ (fetchpatch { url = "https://roy.marples.name/cgit/dhcpcd.git/patch/?id=114870290a8d3d696bc4049c32eef3eed03d6070"; sha256 = "0kzpwjh2gzvl5lvlnw6lis610p67nassk3apns68ga2pyxlky8qb"; }) ]; </ins> preConfigure = "patchShebangs ./configure"; configureFlags = [
Change:
Describe the bug pamtime only uses the example config file in NixOS and is useless without overriding and rebuilding almost every other package. To Reproduce Steps to reproduce the behavior: to add to all pam.d config files. and add . and attempt to ssh as into the machine log in. Expected behavior In the example above, I would expect ssh to forbid from logging in at any time. Additional context Ideally, upstream linux-pam would allow pamtime to be configured at run time similarly to pamenv. However, I would still expect to be able to use pamtime without overriding the linux-pam package to manually change the location of In the current setup, pamtime only ever looks at the example file in the linux-pam package which makes it effectively useless. If the package is overridden to use a different location for that one file, a massive number of packages then needs to be rebuilt manually as they in one way or another depend on pam. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(locus): nixpkgs:
It looks like we may just need to pass and to fix this.
Try this PR:

Discussion:
# which is done by dlopening $out/lib/security/pam_foo.so # $out/etc was also missed: pam_env(login:session): Unable to open config file <del> preConfigure = '' configureFlags="$configureFlags --includedir=$out/include/security" '' + stdenv.lib.optionalString (stdenv.hostPlatform.libc == "musl") '' </del> <ins> preConfigure = stdenv.lib.optionalString (stdenv.hostPlatform.libc == "musl") '' </ins> # export ac_cv_search_crypt=no # (taken from Alpine linux, apparently insecure but also doesn't build O:)) # disable insecure modules

sed -e 's/pam_rhosts//g' -i modules/Makefile.in ''; <ins> configureFlags = [ "--includedir=${placeholder "out"}/include/security" "--enable-sconfigdir=/etc/security" ]; installFlags = [ "SCONFIGDIR=${placeholder "out"}/etc/security" ]; </ins> doCheck = false; # fails meta = with stdenv.lib; {
Change:
Describe the bug Tab completion for man pages does not work in the fish shell. To Reproduce Steps to reproduce the behavior: a fish shell "man " followed by the first few letters of an installed package command tab Expected behavior Fish should complete the man page command. Additional context This appears related to . Metadata system: host os: multi-user?: sandbox: version: channels(jlove): channels(root): nixpkgs: Maintainer information:
Yes, completion for is implemented by calling , which needs a manual cache. PR adds a NixOS option to generate the caches but it's not enabled by default: it's a bit expensive and they have to be regenerated every time a new package is installed. We could enable the caches if is true, what do you think?
I think that makes sense. Fish isn't fully functional without a working , and enabling a program should allow it to work to the best of our ability.
All right, once the change lands in master I'll make another PR for fish. Thank you.

Discussion:
programs.fish.shellAliases = mapAttrs (name: mkDefault) cfge.shellAliases; <ins> # Required for man completions documentation.man.generateCaches = true; </ins> environment.etc."fish/foreign-env/shellInit".text = cfge.shellInit; environment.etc."fish/foreign-env/loginShellInit".text = cfge.loginShellInit; environment.etc."fish/foreign-env/interactiveShellInit".text = cfge.interactiveShellInit;
Change:
My wishlist; feel free to start on some of these yourself: (I had to downgrade that Hydra builder for now) [ ] investigate avoiding the impurity from the builder's nix version. It just makes debugging the failures harder, e.g. now people (with nix = 2.3) will be getting different errors than the Hydra job. [x] investigate getting better error outputs from the job. IIRC now isn't an exception when you see without a good hint of what's wrong (at least what file is referred to).
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 .
I think issues around this are solved now. Anyway, a freshly open one would be probably better for anything that remains.

Discussion:
} '' export NIX_STATE_DIR=$TMPDIR <ins> export NIX_PAGER= </ins> nix-store --init mkdir -p $out/nix-support

# Redirect stdout to /dev/null to avoid hitting "Output Limit # Exceeded" on Hydra. nix-env.qaDrv|nix-env.qaDrvAggressive) <del> NIX_SHOW_STATS=1 time -o stats-time "$@" 2>stats-nix >/dev/null ;; </del> <ins> NIX_SHOW_STATS=1 NIX_SHOW_STATS_PATH=stats-nix time -o stats-time "$@" >/dev/null ;; </ins> *) <del> NIX_SHOW_STATS=1 time -o stats-time "$@" 2>stats-nix ;; </del> <ins> NIX_SHOW_STATS=1 NIX_SHOW_STATS_PATH=stats-nix time -o stats-time "$@" ;; </ins> esac <del> sed '/^warning:/d' -i stats-nix </del> cat stats-nix; echo; cat stats-time; echo x=$(jq '.cpuTime' < stats-nix)

meta.description = "Release-critical builds for the Nixpkgs unstable channel"; constituents = [ jobs.tarball <ins> jobs.metrics </ins> jobs.manual jobs.lib-tests jobs.pkgs-lib-tests
Change:
The soapysdr package contains a Python binding, but it is not possible to use it normally (e.g. via ) because it is not registered as a Python package in nixpkgs. I am not sure what is the proper way of handling this case, since soapysdr is both a regular library and a Python package, and nixpkgs makes a distinction between the two. A workaround is to add. Cc
See the section "15.17.2.2.4. toPythonModule function" in the Nixpkgs manual.

Discussion:
{ stdenv, lib, lndir, makeWrapper , fetchFromGitHub, cmake , libusb, pkgconfig <del> , python, swig2, numpy, ncurses </del> <ins> , usePython ? false , python, ncurses, swig2 </ins> , extraPackages ? [] } :

}; nativeBuildInputs = [ cmake makeWrapper pkgconfig ]; <del> buildInputs = [ libusb ncurses numpy python swig2 ]; </del> <ins> buildInputs = [ libusb ncurses ] ++ lib.optionals usePython [ python swig2 ]; propagatedBuildInputs = lib.optional usePython python.pkgs.numpy; </ins> cmakeFlags = [ "-DCMAKE_BUILD_TYPE=Release" <del> "-DUSE_PYTHON_CONFIG=ON" ]; </del> <ins> ] ++ lib.optional usePython "-DUSE_PYTHON_CONFIG=ON"; </ins> postFixup = lib.optionalString (lib.length extraPackages != 0) '' # Join all plugins via symlinking

soapyhackrf = callPackage ../applications/radio/soapyhackrf { }; <del> soapysdr = callPackage ../applications/radio/soapysdr { inherit (python3Packages) python numpy; }; </del> <ins> soapysdr = callPackage ../applications/radio/soapysdr { }; </ins> soapyremote = callPackage ../applications/radio/soapyremote { }; soapysdr-with-plugins = callPackage ../applications/radio/soapysdr { <del> inherit (python3Packages) python numpy; </del> extraPackages = [ limesuite soapyairspy

snapcast = callPackage ../development/python-modules/snapcast { }; <ins> soapysdr = toPythonModule (pkgs.soapysdr.override { python = self.python; usePython = true; }); soapysdr-with-plugins = toPythonModule (pkgs.soapysdr-with-plugins.override { python = self.python; usePython = true; }); </ins> sparse = callPackage ../development/python-modules/sparse { }; spglib = callPackage ../development/python-modules/spglib { };

certifi = callPackage ../development/python-modules/certifi { }; certipy = callPackage ../development/python-modules/certipy {}; characteristic = callPackage ../development/python-modules/characteristic { }; chart-studio = callPackage ../development/python-modules/chart-studio { };