jiebi/CodeConvo huggingface dataset:
Code change:
Project description The driver supports Realtek 8852AE, which is a wifi card for some new laptops. Without the driver, the wireless interface would be missing for those computers. (My new Lenovo laptop uses this card and I cannot connect to WiFI currently... I'm not entirely sure how to package this) Metadata homepage URL: source URL: license: GPA 2.0 platforms: Linux

Related discussion:
text: rtw88 = callPackage ../os-specific/linux/rtw88 { }; rtlwifi_new = rtw88; <ins> rtw89 = callPackage ../os-specific/linux/rtw89 { }; </ins> openafs_1_8 = callPackage ../servers/openafs/1.8/module.nix { }; openafs_1_9 = callPackage ../servers/openafs/1.9/module.nix { }; # Current stable release; don't backport release updates!
Code change:
Project description The driver supports Realtek 8852AE, which is a wifi card for some new laptops. Without the driver, the wireless interface would be missing for those computers. (My new Lenovo laptop uses this card and I cannot connect to WiFI currently... I'm not entirely sure how to package this) Metadata homepage URL: source URL: license: GPA 2.0 platforms: Linux

Related discussion:
text: rtw88-firmware = callPackage ../os-specific/linux/firmware/rtw88-firmware { }; <ins> rtw89-firmware = callPackage ../os-specific/linux/firmware/rtw89-firmware { }; </ins> s3ql = callPackage ../tools/backup/s3ql { }; sass = callPackage ../development/tools/sass { };
Code change:
Describe the bug With the latest kernel and the latest non-beta nvidia driver, the drivers don't compile: To Reproduce Steps to reproduce the behavior: unstable the latest linux kernel nvidia as a drivers Expected behavior It should compile. Notify maintainers Latest person who touched it: Metadata
I can reproduce this issue, albeit I am using stable channel with the latest kernel.
tl;dr for everyone facing this: should serve as a temporary workaround
I think we should implement some kind of kernel version lock for the nvidia driver to prevent such occurrences in the future.

Related discussion:
text: # Policy: use the highest stable version as the default (on our master). stable = if stdenv.hostPlatform.system == "x86_64-linux" then generic { <del> version = "460.73.01"; sha256_64bit = "120ymf59l6nipczszf82lrm2p4ihhqyv2pfwwfg9wy96vqcckc8i"; settingsSha256 = "08jh7g34p9yxv5fh1cw0r2pjx65ryiv3w2lk1qg0gxn2r7xypkx0"; persistencedSha256 = "040gx4wqp3hxcfb4aba4sl7b01ixr5slhzw0xldwcqlmhpwqphi5"; </del> <ins> version = "470.57.02"; sha256_64bit = "sha256-VdeuEEgn+qeel1Mh/itg+d1C+/9lZCBTRDwOVv20xH0="; settingsSha256 = "sha256-DJg5QbyuKJmPpLQVYgTLvucI1e9YgQOO16690VXIWvk="; persistencedSha256 = "sha256-Cqv6oUFnsSi3S1sjplJKeq9bI2pqgBXPPb11HOJSlDo="; </ins> } else legacy_390;
Code change:
I get the following output from :
Thanks, So fast. :)
This one was rather easy :-)

Related discussion:
text: src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Code change:
Describe the bug The cinnamon-menu-editor doesn't open the cinnamon-desktop-editor, if I want to change the 'Properties' of a menu Entry. To Reproduce https://user- Expected behavior https://user- Additional context Here is the cinnamon-desktop-editor source: Notify maintainers thanks for making cinnamon available in NixOS! :) Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(linux): nixpkgs: Maintainer information:
Open the menu editor through the terminal and edit the properties then send the output
I open cinnamon-menu-editor in Terminal, select an entry, click "Properties": This is in the launcher- :
I marked this as stale due to inactivity. &rarr;
This patch fixes the issue, if nobody wish to investigate on this issue I will go ahead and commit this change on next cinnamon update. Edit: Ah I probably don't need to set dontWrapPythonPrograms Edit 2: Non English user can still encounter some l10n issues like translated strings are not modified, we will track the issue in

Related discussion:
text: intltool gtk-doc perl <ins> python3.pkgs.wrapPython </ins> ]; # use locales from cinnamon-translations (not using --localedir because datadir is used)
Code change:
Describe the bug The cinnamon-menu-editor doesn't open the cinnamon-desktop-editor, if I want to change the 'Properties' of a menu Entry. To Reproduce https://user- Expected behavior https://user- Additional context Here is the cinnamon-desktop-editor source: Notify maintainers thanks for making cinnamon available in NixOS! :) Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(linux): nixpkgs: Maintainer information:
Open the menu editor through the terminal and edit the properties then send the output
I open cinnamon-menu-editor in Terminal, select an entry, click "Properties": This is in the launcher- :
I marked this as stale due to inactivity. &rarr;
This patch fixes the issue, if nobody wish to investigate on this issue I will go ahead and commit this change on next cinnamon update. Edit: Ah I probably don't need to set dontWrapPythonPrograms Edit 2: Non English user can still encounter some l10n issues like translated strings are not modified, we will track the issue in

Related discussion:
text: patchShebangs src/data-to-c.pl ''; <ins> preFixup = '' # https://github.com/NixOS/nixpkgs/issues/101881 gappsWrapperArgs+=( --prefix XDG_DATA_DIRS : "${gnome.caribou}/share" ) # https://github.com/NixOS/nixpkgs/issues/129946 buildPythonPath "${python3.pkgs.xapp}" patchPythonScript $out/share/cinnamon/cinnamon-desktop-editor/cinnamon-desktop-editor.py ''; </ins> passthru = { providedSessions = [ "cinnamon" "cinnamon2d" ]; };
Code change:
Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . 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:

Related discussion:
text: <del> { lib, stdenv, fetchurl, makeWrapper, jre8, which, gawk }: </del> <ins> { lib, stdenv, fetchurl, makeWrapper, jre, which, gawk }: </ins> with lib;
Code change:
Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . 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:

Related discussion:
text: }; nativeBuildInputs = [ makeWrapper ]; <del> buildInputs = [ jre8 which gawk ]; </del> installPhase = '' mkdir -p "$out/share/neo4j"
Code change:
Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . 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:

Related discussion:
text: do makeWrapper "$out/share/neo4j/bin/$NEO4J_SCRIPT"  "$out/bin/$NEO4J_SCRIPT"  <del> --prefix PATH : "${lib.makeBinPath [ jre8 which gawk ]}"  --set JAVA_HOME "$jre8" </del> <ins> --prefix PATH : "${lib.makeBinPath [ jre which gawk ]}"  --set JAVA_HOME "${jre}" </ins> done '';
Code change:
Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . 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:

Related discussion:
text: check_systemd = callPackage ../servers/monitoring/nagios/plugins/check_systemd.nix { }; <del> neo4j = callPackage ../servers/nosql/neo4j { }; </del> <ins> neo4j = callPackage ../servers/nosql/neo4j { jre = jre8_headless; }; </ins> neo4j-desktop = callPackage ../applications/misc/neo4j-desktop { };
Code change:
Describe the bug In the 21.05 VirtualBox OVA you can download from there is no disk space available, making it impossible to use for almost anything: To Reproduce Steps to reproduce the behavior: the VirtualBox OVA from , the instructions on above page to import and start it (although the instructions are a bit outdated too, no need to log in manually) in a Konsole window Expected behavior I expect to have disk space. Here's the same for a NixOS 20.09 OVA: Screenshots ! Notify maintainers Metadata Bad nixpkgs version (21.05): Good nixpkgs version (20.09): Maintainer information:
hmm, well we can add a new option to the for the additional disk space in the image. We then could pass the value to from
I think that's setting the disk image size. Which is given here: I haven't had time to take a look, I wonder what looks like; is it a situation where fails?
Right, so assumption seems more right. Good to know.

Related discussion:
text: The size of the VirtualBox base image in MiB. ''; }; <ins> baseImageFreeSpace = mkOption { type = with types; int; default = 30 * 1024; description = '' Free space in the VirtualBox base image in MiB. ''; }; </ins> memorySize = mkOption { type = types.int; default = 1536;
Code change:
Describe the bug In the 21.05 VirtualBox OVA you can download from there is no disk space available, making it impossible to use for almost anything: To Reproduce Steps to reproduce the behavior: the VirtualBox OVA from , the instructions on above page to import and start it (although the instructions are a bit outdated too, no need to log in manually) in a Konsole window Expected behavior I expect to have disk space. Here's the same for a NixOS 20.09 OVA: Screenshots ! Notify maintainers Metadata Bad nixpkgs version (21.05): Good nixpkgs version (20.09): Maintainer information:
hmm, well we can add a new option to the for the additional disk space in the image. We then could pass the value to from
I think that's setting the disk image size. Which is given here: I haven't had time to take a look, I wonder what looks like; is it a situation where fails?
Right, so assumption seems more right. Good to know.

Related discussion:
text: inherit pkgs lib config; partitionTableType = "legacy"; diskSize = cfg.baseImageSize; <ins> additionalSpace = cfg.baseImageFreeSpace; </ins> postVM = ''
Code change:
Helvum build is broken on unstable Steps to reproduce the behavior: master helvum Build suceeds. Since it's pipewire-sys crate that fails, I suspect it was a pipewire upgrade that broke it Maintainer information:
Trying to build latest helvum master, as it's now been updated to use pipewire from Will post updates.
Alright, it fails even with the latest master, so I assume it's a pipewire error. is the maintainer of the PipeWire package and the leader of the PipeWire efforts on Nix/OS so they may know more about this. In the meantime, helvum will remain broken :(
Is it the same error? Could be that the bindings need an upgrade to support the newer version of pipewire because of changed APIs. Then that would be a bug in the pipewire-sys crate.
Yes, it's exactly the same error. You're right, I'll look into pipewire-related issues on GitLab to try and see what's going on.
I found , which means we have to wait a bit until that gets merged.
The issue links to this pull request: Not sure how it's with crates, but the dependency could be patched using this patch: (This is the alternative to waiting until that's resolved)
Sure, I'll get to work then.
Strictly speaking I'm not officially maintaining the pipewire package, but I guess I've effectively become the de facto maintainer anyway.
Sorry for mispinging you then!
No problem. I originally just wanted to get some progress and organization in the messy packaging situation. I hope that the official maintainers and autoupdate bot can take over again once upstream stabilizes more. I'm not actually sure who exactly the official maintainers would be, though. The package just says "freedesktop maintainers". EDIT: and I did end up following upstream development pretty closely so pinging me was a very reasonable guess.
as it currently stands, I don't think it's possible to override the dependency with a nix-built one. Though I have made a nix derivation for it, there's no way to propagate it to using . In turn, I'll wait and see what Ryuukyu does upstream.
I've fixed pipewire-rs and helvum and made a new release, so it should now build again once you update the package.
! Can confirm it works. Thanks

Related discussion:
text: rustPlatform.buildRustPackage rec { pname = "helvum"; <del> version = "0.2.1"; </del> <ins> version = "0.3.0"; </ins> src = fetchFromGitLab { domain = "gitlab.freedesktop.org"; owner = "ryuukyu"; repo = pname; rev = version; <del> sha256 = "sha256-ZnpdGXK8N8c/s4qC2NXcn0Pdqrqr47iOWvVwXD9pn1A="; </del> <ins> sha256 = "sha256-AlHCK4pWaoNjR0eflxHBsuVaaily/RvCbgJv/ByQZK4="; </ins> }; <del> cargoSha256 = "sha256-2v2L20rUWftXdhhuE3wiRrDIuSg6VFxfpWYMRaMUyTU="; </del> <ins> cargoSha256 = "sha256-mAhh12rGvQjs2xtm+OrtVv0fgG6qni/QM/oRYoFR7U8="; </ins> nativeBuildInputs = [ clang copyDesktopItems pkg-config ]; buildInputs = [ glib gtk4 pipewire ];
Code change:
, CVSSv3=5.3 (nixos-21.05, nixos-unstable) For Eclipse Jetty versions 9.4.37-9.4.42, 10.0.1-10.0.5 & 11.0.1-11.0.5, URIs can be crafted using some encoded characters to access the content of the WEB-INF directory and/or bypass some security constraints. This is a variation of the vulnerability reported in CVE-2021-/GHSA-v7ff-8wcx-gmc5. Scanned versions: nixos-21.05: ; nixos-unstable: . Cc

Related discussion:
text: stdenv.mkDerivation rec { pname = "jetty"; <del> version = "9.4.41.v20210516"; </del> <ins> version = "9.4.43.v20210629"; </ins> src = fetchurl { url = "https://repo1.maven.org/maven2/org/eclipse/jetty/jetty-distribution/${version}/jetty-distribution-${version}.tar.gz"; <del> sha256 = "sha256-hFQC1UiqZbbvyMf1FC3eqvVga3QdPWh0fbotatkVHBI="; </del> <ins> sha256 = "sha256-AfrmVLCZMuRGAZqoWeevbgXifbreErVM17rjJJ/HI9k="; </ins> }; dontBuild = true;
Code change:
Shutter fails to build, looks like an issue with Imagemagick. Steps to reproduce the behavior: Expect that it should build, it was working on my last generation. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Maintainer information: Probably related to
'shutter' is outdated in nixpkgs, perhaps we should start with a package update.
That would be nice but I think the problem is due to changes in perl packages
i tested and fixes this
I'll update shutter but will make the pr after the above pr has been merged

Related discussion:
text: }; }; <ins> GooCanvas2CairoTypes = buildPerlPackage rec { pname = "GooCanvas2-CairoTypes"; version = "0.001"; src = fetchurl { url = "mirror://cpan/authors/id/A/AS/ASOKOLOV/GooCanvas2-CairoTypes-${version}.tar.gz"; sha256 = "sha256-uoBnNuvMnePYFBp2Omgr3quxy4cCveKZrf1XSs6HUFI="; }; propagatedBuildInputs = [ pkgs.goocanvas2 Gtk3 ]; meta = { description = "Bridge between GooCanvas2 and Cairo types"; license = with lib.licenses; [ artistic1 gpl1Plus ]; }; }; </ins> GoogleProtocolBuffers = buildPerlPackage { pname = "Google-ProtocolBuffers"; version = "0.12";
Code change:
Shutter fails to build, looks like an issue with Imagemagick. Steps to reproduce the behavior: Expect that it should build, it was working on my last generation. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Maintainer information: Probably related to
'shutter' is outdated in nixpkgs, perhaps we should start with a package update.
That would be nice but I think the problem is due to changes in perl packages
i tested and fixes this
I'll update shutter but will make the pr after the above pr has been merged

Related discussion:
text: }; }; <del> Gtk3ImageView = buildPerlPackage { </del> <ins> Gtk3ImageView = buildPerlPackage rec { </ins> pname = "Gtk3-ImageView"; <del> version = "6"; </del> <ins> version = "9"; </ins> src = fetchurl { <del> url = "mirror://cpan/authors/id/R/RA/RATCLIFFE/Gtk3-ImageView-6.tar.gz"; sha256 = "0krkif9i3hrgjdskw05pcks40fmb43d21lxf4h8aclv0g8z647f0"; </del> <ins> url = "mirror://cpan/authors/id/A/AS/ASOKOLOV/Gtk3-ImageView-${version}.tar.gz"; sha256 = "sha256-0dxe0p1UQglq+xok7g4l2clJ9WqOHxCeAzWD65E0H9w="; </ins> }; buildInputs = [ pkgs.gtk3 ]; propagatedBuildInputs = [ Readonly Gtk3 ]; <del> checkInputs = [ TestDifferences ImageMagick TryTiny TestMockObject CarpAlways pkgs.librsvg ]; </del> <ins> checkInputs = [ TestDifferences TestDeep ImageMagick TryTiny TestMockObject CarpAlways pkgs.librsvg ]; </ins> checkPhase = '' ${pkgs.xvfb-run}/bin/xvfb-run -s '-screen 0 800x600x24'  make test
Code change:
Thought I'd try out Opentoonz because it looks cool, however I can't get the derivation for libtiff-4.0.3-opentoonz (patched version of libtiff for opentoonz) to build. Steps to reproduce the behavior: on NixOS 21.05 -4.0.3-opentoonz derivation fails to build to successfully evaluate and drop me to a shell prompt from whence I can run and try out Opentoonz. This is the relevant output from :
the build of opentoonz is also failing on master but for a different reason

Related discussion:
text: { boost, cmake, fetchFromGitHub, freeglut, freetype, glew, libjpeg, libmypaint <del> , libpng, libtiff, libusb1, lz4, xz, lzo, openblas, pkg-config, qtbase , qtmultimedia, qtscript, lib, stdenv, superlu, wrapQtAppsHook, }: </del> <ins> , libpng, libtiff, libusb1, lz4, xz, lzo, openblas, opencv, pkg-config, qtbase , qtmultimedia, qtscript, qtserialport, lib, stdenv, superlu, wrapQtAppsHook, }: </ins> let source = import ./source.nix { inherit fetchFromGitHub; }; in stdenv.mkDerivation rec { inherit (source) src;
Code change:
Thought I'd try out Opentoonz because it looks cool, however I can't get the derivation for libtiff-4.0.3-opentoonz (patched version of libtiff for opentoonz) to build. Steps to reproduce the behavior: on NixOS 21.05 -4.0.3-opentoonz derivation fails to build to successfully evaluate and drop me to a shell prompt from whence I can run and try out Opentoonz. This is the relevant output from :
the build of opentoonz is also failing on master but for a different reason

Related discussion:
text: xz lzo openblas <ins> opencv </ins> qtbase qtmultimedia qtscript <ins> qtserialport </ins> superlu ];
Code change:
Thought I'd try out Opentoonz because it looks cool, however I can't get the derivation for libtiff-4.0.3-opentoonz (patched version of libtiff for opentoonz) to build. Steps to reproduce the behavior: on NixOS 21.05 -4.0.3-opentoonz derivation fails to build to successfully evaluate and drop me to a shell prompt from whence I can run and try out Opentoonz. This is the relevant output from :
the build of opentoonz is also failing on master but for a different reason

Related discussion:
text: { fetchFromGitHub, }: rec { versions = { <del> opentoonz = "1.4.0"; libtiff = "4.0.3"; </del> <ins> opentoonz = "1.5.0"; libtiff = "4.0.3";  # The version in thirdparty/tiff-* </ins> }; src = fetchFromGitHub { owner = "opentoonz"; repo = "opentoonz"; rev = "v${versions.opentoonz}"; <del> sha256 = "0vgclx2yydsm5i2smff3fj8m750nhf35wfhva37kywgws01s189b"; </del> <ins> sha256 = "1rw30ksw3zjph1cwxkfvqj0330v8wd4333gn0fdf3cln1w0549lk"; </ins> }; }
Code change:
Thought I'd try out Opentoonz because it looks cool, however I can't get the derivation for libtiff-4.0.3-opentoonz (patched version of libtiff for opentoonz) to build. Steps to reproduce the behavior: on NixOS 21.05 -4.0.3-opentoonz derivation fails to build to successfully evaluate and drop me to a shell prompt from whence I can run and try out Opentoonz. This is the relevant output from :
the build of opentoonz is also failing on master but for a different reason

Related discussion:
text: opentimestamps-client = python3Packages.callPackage ../tools/misc/opentimestamps-client {}; <del> opentoonz = (qt514.overrideScope' (_: _: { libtiff = callPackage ../applications/graphics/opentoonz/libtiff.nix { }; })).callPackage ../applications/graphics/opentoonz { }; </del> <ins> opentoonz = let opentoonz-libtiff = callPackage ../applications/graphics/opentoonz/libtiff.nix { }; in qt5.callPackage ../applications/graphics/opentoonz { libtiff = opentoonz-libtiff; opencv = opencv.override { libtiff = opentoonz-libtiff; }; }; </ins> opentabletdriver = callPackage ../tools/X11/opentabletdriver { };
Code change:
tpm2-tss is unable to resolve the tabrmd loader located in the tpm2-abrmd package throwing this error when Steps to reproduce the behavior: the abrmd daemon and set the tcti environment interface to tabrmd tool or package using the tpm2-tss library It resolves the loader dynamically and works. I have narrowed down the cause to this commit making the dynamic loader only resolve locally from the library output. Reverting this in an overlay seems to have fixed the issue, but I am unsure if this would cause regressions as I am unsure why the dynamic loading got patched in the first place.
I patched the tpm2-tss because when using tpm2 as a library, the modules would not be up in the dlopen load path which would break modules loading. A couple more details here:
This was a bit more tricky than I expected, while other python packages gets the dlopen library name patched with the exact path this is not possible in this case due to tpm2-tss doing the loading as far I understand. Unless I remember wrong I think it might be possible to dlopen with the exact path in python before calling tpm2-tss init and ld might be able to resolve the already library loaded library, but I might remember wrong. But this would also be undesirable since you cannot dynamically resolve loaders this way I assume.
Ha! So the issue would be that tabmd tries to look up libtss2-tcti- and this is provided by tpm2-abrmd. I completely missed that.

Related discussion:
text: substituteInPlace src/tss2-tcti/tctildr-dl.c  --replace '@PREFIX@' $out/lib/ substituteInPlace ./test/unit/tctildr-dl.c  <del> --replace ', "libtss2' ", "$out/lib/libtss2"  --replace ', "foo' ", "$out/lib/foo"  --replace ', TEST_TCTI_NAME' ", "$out/lib/"TEST_TCTI_NAME" </del> <ins> --replace '@PREFIX@' $out/lib </ins> ''; configureFlags = [