jiebi/CodeConvo huggingface dataset:
Change:
<del> { pkgs , buildPythonPackage , fetchPypi , azure-mgmt-common , python }: buildPythonPackage rec { version = "0.20.1"; pname = "azure-mgmt-network"; src = fetchPypi { inherit pname version; extension = "zip"; sha256 = "10vj22h6nxpw0qpvib5x2g6qs5j8z31142icvh4qk8k40fcrs9hx"; }; preConfigure = '' # Patch to make this package work on requests >= 2.11.x # CAN BE REMOVED ON NEXT PACKAGE UPDATE sed -i 's|len(request_content)|str(len(request_content))|' azure/mgmt/network/networkresourceprovider.py ''; postInstall = '' echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/__init__.py echo "__import__('pkg_resources').declare_namespace(__name__)" >> "$out/lib/${python.libPrefix}"/site-packages/azure/mgmt/__init__.py ''; propagatedBuildInputs = [ azure-mgmt-common ]; meta = with pkgs.lib; { description = "Microsoft Azure SDK for Python"; homepage = "https://azure.microsoft.com/en-us/develop/python/"; license = licenses.asl20; maintainers = with maintainers; [ olcai ]; }; } </del>

Discussion:
After in nixops, we can remove the locally pinned version in nixpkgs.
Not yet, I would like to keep those for building nixops v1.6.1 for any users of the Azure backend.
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 .
Change:
gdk-pixbuf glib glibc <del> gtk2 </del> gtk3 libkrb5 mesa

Discussion:
firefox-bin package requires gtk2 despite firefox doesn't use gtk2 for a long time Steps to reproduce the behavior: any of packages from the firefox-bin family firefox-bin doesn't install gtk2 as dependency
I can reproduce this for your commit, but cannot reproduce with current master, potentially it was fixed, can you confirm?
You're checking firefox rather than firefox-bin in the second output :thinking:
Change:
</listitem> <listitem> <para> <ins> Linux 4.9 has been removed because it will reach its end of life within the lifespan of 22.11. </para> </listitem> <listitem> <para> </ins> (Neo)Vim can not be configured with <literal>configure.pathogen</literal> anymore to reduce maintainance burden. Use <literal>configure.packages</literal>

Discussion:
The Linux 4.9 LTS release will be EOL after 2023/01 and I hope we can remove it before the 22.11 release, so we don't carry it around until then. via cc kernel maintainer team
Thanks for the heads-up. I'd be fine with doing the removal right now (considering that it's LTS and having that one removed on stable may be an unpleasant surprise), but FWIW: we usually drop kernel releases when they get EOLed (also from stable branches), otherwise we wouldn't be able to provide non-LTS kernels on any stable branch anyways.
Change:
<ins> { lib , stdenv , fetchFromGitHub , hidapi , profile ? "/etc/g810-led/profile" }: stdenv.mkDerivation rec { pname = "g810-led"; version = "0.4.3"; src = fetchFromGitHub { owner = "MatMoul"; repo = pname; rev = "refs/tags/v${version}"; hash = "sha256-GKHtQ7DinqfhclDdPO94KtTLQhhonAoWS4VOvs6CMhY="; }; postPatch = '' substituteInPlace udev/g810-led.rules  --replace "/usr" $out  --replace "/etc/g810-led/profile" "${profile}" ''; buildInputs = [ hidapi ]; installPhase = '' runHook preInstall install -D bin/g810-led $out/bin/g810-led # See https://github.com/MatMoul/g810-led#compatible-keyboards- for keyboard in {g213,g410,g413,g512,g513,g610,g815,g910,gpro}; do ln -s ./g810-led $out/bin/$keyboard-led done install -D udev/g810-led.rules $out/etc/udev/rules.d/90-g810-led.rules runHook postInstall ''; meta = with lib; { description = "Linux LED controller for some Logitech G Keyboards"; homepage = "https://github.com/MatMoul/g810-led"; license = licenses.gpl3Only; maintainers = with maintainers; [ fab ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description Linux led controller for Logitech G213, G410, G413, G512, G513, G610, G810, G815, G910 and GPRO Keyboards. Metadata homepage URL: source URL: license: gpl3 platforms: linux
There are closed pull requests for both a and . If you want to you can update it based on the suggestions and open your own PR.
I marked this as stale due to inactivity. &rarr;
Change:
preFixup = '' gappsWrapperArgs+=( <del> --prefix PATH : "${lib.makeBinPath [ gpart hdparm util-linux procps coreutils gnused gnugrep ]}" </del> <ins> --prefix PATH : "${lib.makeBinPath [ gpart hdparm util-linux procps coreutils gnused gnugrep mtools dosfstools ]}" </ins> ) '';

Discussion:
Describe the bug GParted in the installation ISO images cannot create, resize, move and do other operations on many filesystems such as FAT32. This problem is due to absence of related (optional) run-time dependencies such as and (in the case of FAT32). in live session doesn't solve the problem. The supports to filesystems other than ext4 is important especially when you need to operate on the EFI System Partition (ESP), NTFS for Windows, HFS for Mac, and BTRFS used by some other Linux distributions. Possible solution includes: all the run-time dependencies required for GParted to operate on those filesystems in the list in . a new package, , and show it in . Replace with 'gparted-full' in list in . To Reproduce Steps to reproduce the behavior: Go to and download the 64bit Plasma Desktop ISO image, which is the image after burning it to a USB stick or attaching to a virtual machine. sure that there is a FAT32 partition on your machine. Most computers have EFI System Partition, which is usually FAT32. If there isn't any, an USB stick with a FAT32 partition can be attachede GParted and right-click on the FAT32 partition, it can be noticed that some options including are grayed out. -click on an un-allocated space, click , and it can be seen that many options including FAT32 have been grayed out. Expected behavior GParted on the ISO installation image can operate on all or most of the supported file systems. Screenshots If applicable, add screenshots to help explain your problem. Additional context Filesystems supported by GParted: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I had the same issue now.
Related
Change:
if [ -d "plugins/remote-dev-server" ]; then patch -p1 < ${./JetbrainsRemoteDev.patch} fi <ins> vmopts_file=bin/linux/${vmoptsName} if [[ ! -f $vmopts_file ]]; then vmopts_file=bin/${vmoptsName} if [[ ! -f $vmopts_file ]]; then echo "ERROR: $vmopts_file not found" exit 1 fi fi echo -Djna.library.path=${lib.makeLibraryPath ([ libsecret e2fsprogs libnotify # Required for Help -> Collect Logs # in at least rider and goland udev ])} >> $vmopts_file </ins> ''; installPhase = ''

Discussion:
A clear and concise description of what the bug is. JetBrains editors run with which result in project built under the editors (i.e. in 's terminal) always picks up from . Even if the project is using for example . This result in ABI conflict when the build executable runs, because other components - which built using , outside clion - use from Steps to reproduce the behavior: well, this might be tricky to prepare a small project needed to support itself, should not leak into projects it edits  I suspect and in are problematic too introduced in
it seems that the fix should be to use command line switch instead of environment variable
And (or ), because JNA is looking for .so files there, so should be on one of them instead of
This is still a problem
Can confirm, this is an issue when using per-project environments which are on a different channel than my systems'. Shouldn't the "internals" be patched using e.g. instead?
For anyone else running into this: the workaround is to clear the environment variable in the IDE settings for the commands you want to run. Cumbersome, but it works.
The above workaround doesn't completely work. For instance, there is no way to remove when setting the project interpreter in PyCharm.
The following seems to work: I'll try to prepare a PR in the coming days. EDIT: It even discovered some missing dependencies and .
Has there been an update on this? I am trying to use prettier in Webstorm and all other tools to have needed the to be reset, if I want to run them. But this is not possible for prettier. I suspect that it would work with unset.
Just had this come up again trying to build a program with gcc 13 in CLion. Simply removing from in fixes the issue and doesn't appear to break clion, idea, or rider.
Change:
<ins> diff --git a/comm/mail/config/mozconfigs/common b/comm/mail/config/mozconfigs/common --- a/comm/mail/config/mozconfigs/common +++ b/comm/mail/config/mozconfigs/common @@ -1,6 +1,3 @@ ac_add_options --enable-application=comm/mail -# Disable enforcing that add-ons are signed by the trusted root. -MOZ_REQUIRE_SIGNING= - . "$topsrcdir/build/mozconfig.common.override" diff --git a/comm/mail/moz.configure b/comm/mail/moz.configure --- a/comm/mail/moz.configure +++ b/comm/mail/moz.configure @@ -12,6 +12,7 @@ imply_option("MOZ_CRASHREPORTER_URL", "https://crash-reports.thunderbird.net/") imply_option("--enable-default-browser-agent", False) +imply_option("MOZ_REQUIRE_SIGNING", False) @depends(target_is_windows, target_is_linux) </ins>

Discussion:
As explained also here: Steps to reproduce the behavior: Thunderbird 91 to install any extensions fail with "Thunderbird has prevented this site from installing an unverified add-on" Add on is instaalled successfully system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
I can't find any obvious explanation for this, since both Firefox 91 and Thunderbird 78 using the same build expression can install add-ons fine. As a workaround you can use thunderbird-78, which is still present on nixos-unstable and seems to work fine.
Yes, downgrading seems to be working. However I would still have an up to date thunderbird. Also are you reproducing this on TB 91?
I can reproduce the problem.
And installed ones can't be enabled. (except for themes and dictionaries)
Haven't tried my nixos instance yet but this is probably an upstream Thunderbird issue with linux - my test Ubuntu systems are all exhibiting the same problems with 91. Clean install or upgrade over 78 makes no difference. I can't even enable/disable themes. Predictably - and annoyingly - my Win10 Thunderbird 91 tests with addons all work fine.
yeah Downloading extensions from in Thunderbird 91 works for me as well. Just not
From the thread above, looks like: Thunderbird downloaded from works fine. Rebuilding with "" fixes add-ons and language packs verification issue.
Ok so why thunderbird does not trusts ?
Well, it does if the thunderbird binary is from So probably some changes to how things are built.
After rebuilding thunderbird with MOZREQUIRESIGNING= normal behaviour is only restored for new profiles I create - annoyingly my existing profile (the one I care about, obviously) is still unable to install or activate addons/themes. It's not a Mozilla issue as the tar ball of 91 direct from them works fine. It seems to be a common artefact introduced into the distro release by - that I know of so far - NixOS, Slackware, Fedora and Ubuntu. Which is pretty weird.
Here's the upstream bug report: In the mean time, distribution build changes are the only way to fix this.
Cannot, have never been able to add those tempting add-ons. Thunderbird says 'this add-on will have access to , etc. but clicking never does anything
Change:
<del> { lib, buildPythonPackage, fetchPypi , six, cryptography , mock, pyfakefs </del> <ins> { lib , buildPythonPackage , fetchPypi , six , cryptography , mock , pyfakefs </ins> }: buildPythonPackage rec { pname = "fido2"; <del> version = "0.7.3"; </del> <ins> version = "0.8.1"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "8b592ec0e51348f29636706fe3266423a0e41c35c9df63a259a91488450c1285"; </del> <ins> sha256 = "1hzprnd407g2xh9kyv8j8pq949hwr1snmg3fp65pqfbghzv6i424"; </ins> }; propagatedBuildInputs = [ six cryptography ];

Discussion:
Describe the bug Since the commit this package does not build. It fails with the following output: To Reproduce Steps to reproduce the behavior: Expected behavior Package should be building without errors. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Can reproduce, strange. Good news is bumping (as I happened to do locally earlier today for other reasons, haha) seems to fix things-- can you confirm that moving to 0.8.1 as in fixes this?
I can confirm that bump to 0.8.1 fixes the build. (However we have 0.7.3 already in master, so the change from does not apply cleanly). I sent the PR in where I also add myself as a maintainer.
Change:
meta.homepage = "https://github.com/chrisbra/SudoEdit.vim/"; }; <del> TrueZen-nvim = buildVimPluginFrom2Nix { pname = "TrueZen.nvim"; version = "2022-08-07"; src = fetchFromGitHub { owner = "Pocco81"; repo = "true-zen.nvim"; rev = "98740c76254c65576ec294551028b65081053588"; sha256 = "1g7wwb081yliqzpzmgjgvv9fn9qcry9k4xbgv0zcgz7z1lbhmyj1"; }; meta.homepage = "https://github.com/Pocco81/true-zen.nvim/"; }; </del> VimCompletesMe = buildVimPluginFrom2Nix { pname = "VimCompletesMe"; version = "2022-02-18";

Discussion:
Building the TrueZen-nvim plugin on nixpkgs master leads to the evaluation error: Steps to reproduce the behavior: TrueZen-nvim builds. It seems that the attribute is deprecated, but the new attribute () does not exist in . I'm not sure what's going on here. The change originates from , but TrueZen-nvim was updated automatically. since it seems like an update script issue?
I've got my hands full at the moment so feel free to take a stab at it.
Change:
meta.maintainers = with lib.maintainers; [ rhoriguchi ]; })) <ins> (patchExtension "x11gestures@joseexposito.github.io" (old: { # Extension can't find Touchegg # https://github.com/NixOS/nixpkgs/issues/137621 postPatch = '' substituteInPlace "src/touchegg/ToucheggConfig.js"  --replace "GLib.build_filenamev([GLib.DIR_SEPARATOR_S, 'usr', 'share', 'touchegg', 'touchegg.conf'])" "'${touchegg}/share/touchegg/touchegg.conf'" ''; })) </ins> ]

Discussion:
(from ) is a GNOME extension which searches for the package in Because it can't detect the installed package it sends a notification that the package must be installed, and subsequently does not inhibit the default gestures provided by the package. Also, there is no built-in way to tell it to use another path. Steps to reproduce the behavior: the and (Please see additional context) packages the X11 Gestures extension The extension must recognize the actual path for in and work properly Since the package in the repos is extremely outdated (v1.1.1), I am using an to install the latest version v2.0.11 (see for updating the package in the repos). Also, may be relevant Extensions maintainer Creator of the extension and
I'll see how difficult it is to fix the path. However, I am reluctant to do custom dependencies patches, so I'd block this on .
I don't think there are any custom dependency patches required (it is just an extension, and apart from inhibiting the default gestures, it works properly as is).
I think is where it searches for the system config, to determine if the package is installed EDIT: Confirmed that editing and replacing with path in fixes the issue
Why ? Wouldn't it be better on ? Has anyone done this patch? Let's do it?
That should be the best thing to do. I've tried to patch the extension using , but for some reason it doesn't seem to work, and I'm pretty new to Nix, so I've just left it for the time-being
Ops, forgot to notify it here. I fixed this by following the . Both the GNOME extension and Touchégg use the env var to find the system configuration: The same applies for the user config with : A NixOS maintainer suggested this fix.
Thanks a lot! seems to have updated the extension to the version which has the fixes, so I'll close this issue
I think that the needs to be set in the package to point to the right path. Not sure if that work is done though, since I'm not a NixOS user...
Still i get it ! The gestures works with default touchegg gestures on the same time. Switching to next workspace and snap window to half side screen !
I made a workaround. I created a blank .

So the extension managed to populate the file with its gestures and now I only have the extension gestures. But the "Not installed" alert still persist.
My conf dirs: It's not in any of these places. It's in
In that case you'd need to add at the end of . However, I'm not sure what's the NixOS way of doing it. I'm sure there is a way to fix this in the package.
Ok. Thanks!
help us with your review on
Change:
python3.pkgs.buildPythonApplication rec { pname = "snakemake"; <del> version = "7.14.2"; </del> <ins> version = "7.25.3"; </ins> format = "setuptools"; src = fetchFromGitHub { owner = "snakemake"; repo = pname; rev = "refs/tags/v${version}"; <del> hash = "sha256-4XduybmDmlux3zvjbN1ouaJ1PkNO8h6vHuxgZ3YLBrw="; </del> <ins> hash = "sha256-KrstajTocVX5Tw7aiPoJ9vxJ0nKF+jqJcYJKrJvBt0Q="; </ins> }; propagatedBuildInputs = with python3.pkgs; [

Discussion:
A clear and concise description of what the bug is. Steps to reproduce the behavior: a simple Snakefile such as shown below command fails with (truncated) exception message as shown below The command does not fail with an exception This is a known issue that has been fixed in the recent versions of Snakemake Please run and paste the result.
Change:
# Vulkan developer beta driver # See here for more information: https://developer.nvidia.com/vulkan-driver vulkan_beta = generic rec { <del> version = "525.47.04"; persistencedVersion = "525.78.01"; settingsVersion = "525.78.01"; sha256_64bit = "sha256-PcDRM39s4vh5++4TocIJKI3wsxWxJdy3p3KAenpdIc0="; openSha256 = "sha256-jH7mwSpasOdWMvN1xuPkO33g0XJjObzA45aqHwKoD4w="; settingsSha256 = "sha256-1d3Cn+7Gm1ORQxmTKr18GFmYHVb8t050XVLler1dCtw="; persistencedSha256 = "sha256-t6dViuvA2fw28w4kh4koIoxh9pQ8f7KI1PIUFJcGlYA="; url = "https://developer.nvidia.com/vulkan-beta-${lib.concatStrings (lib.splitString "." version)}-linux"; </del> <ins> version = "525.47.06"; persistencedVersion = "525.85.05"; settingsVersion = "525.85.05"; sha256_64bit = "sha256-HxRXtd3ubjS1V/y1hDWe16XNSCbQYHoEw+Jz8Emy5/4="; openSha256 = "sha256-oiOlCdkFMXm4vVZzmnnI5/INVWUqC02gGj/aIfzjGig="; settingsSha256 = "sha256-ck6ra8y8nn5kA3L9/VcRR2W2RaWvfVbgBiOh2dRJr/8="; persistencedSha256 = "sha256-dt/Tqxp7ZfnbLel9BavjWDoEdLJvdJRwFjTFOBYYKLI="; url = "https://developer.nvidia.com/downloads/vulkan-beta-${lib.concatStrings (lib.splitString "." version)}-linux"; </ins> }; # Update note:

Discussion:
Steps to reproduce the behavior: linuxKernel.packages.linuxzen.nvidiax11vulkanbeta form nixos-unstable. The NVIDIA driver URL for the Vulkan beta developer driver seems to be incorrect. I tried using from in a web browser and the site actually returns a 404 error. The actual download URL seems to have been changed to . Entering this URL into the web browser starts the download as well. Please run and paste the result.
How can I overrule this for now so I can build my system :p ?
I'm not sure myself I tried to make an overlay like I used to for other packages but it failed to build altogether. Although my Nix-fu is still quite limited :D.
I tried exactly the same. But just like you, my Nix-fu is also quite limited haha
Thanks for the quick fix and I really appreciate your efforts. Now we just have to wait for the fix to come to :D.
For now, you may set: (disclaimer: did not test, could be wrong)
Change:
homepage = "https://sourceforge.net/p/bibutils/home/Bibutils/"; license = licenses.gpl2; maintainers = [ maintainers.garrison ]; <del> platforms = platforms.linux; </del> <ins> platforms = platforms.unix; </ins> }; }

Discussion:
Building the package produces a large number of compiler warnings, and then fails with ... risout.c:111:26: note: previous initialization is here [ 0 ... NUMTYPES-1 ] = 0, ^ 8 warnings generated. ld: unknown option: -soname clang-7: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: [Makefile:83: ] Error 1 make[1]: Target 'all' not remade because of errors. make: [Makefile:40: all] Error 2 builder for '/nix/store/bqwyr2gywrffh3xrwplhi4sv7962d21r-bibutils-' failed with exit code 2 error: build of '/nix/store/bqwyr2gywrffh3xrwplhi4sv7962d21r-bibutils-' failed I have built bibutils by hand on macOS, without difficulty (I last tried it on 10.15), so it's not something intrinsically broken in the upstream package. I hope, therefore, it just requires a minor tweak in the Nix package. I note from that macOS isn't one of the listed supported platforms. I'm a little uncertain how best to report my current environment, but: OS : macOS 11.3.1 compiler: Apple clang version 11.0.3 (clang-1103.0.32.29) ; Target: x8664-apple-darwin20.4.0 nix --version: nix (Nix) 2.3.9
Change:
<del> { lib, stdenv, fetchFromGitHub, pkg-config, makeWrapper, ncurses, readline , archivemount, atool, fzf, libarchive, rclone, sshfs, unzip, vlock , conf ? null, withIcons ? false, withNerdIcons ? false }: </del> <ins> { lib , stdenv , fetchFromGitHub , installShellFiles , makeWrapper , pkg-config , file , ncurses , readline , which # options , conf ? null , withIcons ? false , withNerdIcons ? false }: </ins> # Mutually exclusive options assert withIcons -> withNerdIcons == false;

Discussion:
Describe the bug nnn fails to install on MacOs (darwin) because archivemount is not supported on darwin platform To Reproduce Steps to reproduce the behavior: -shell -p nnn Notify maintainers Metadata Please run and paste the result. Maintainer information:
This is fixed in . <details</details
Actually, that wasn't enough. I overlooked that archivemount was only a part of . For the latest nnn to build on Darwin, the vlock dependency would have to be disabled. Moreover, the dependencies that were are command line utilities that nnn can optionally use if installed. As these are command line utilities that users would typically choose to explicitly install if needed, I think it's enough to let nnn pick up the available commands from at runtime rather than having the nnn package depend on them. Or maybe introduce an option (e.g., ) to include those dependencies.