jiebi/CodeConvo huggingface dataset:
Change:
patchExecutable genymotion patchExecutable player <ins> patchExecutable qemu/x86_64/bin/qemu-img patchExecutable qemu/x86_64/bin/qemu-system-x86_64 </ins> patchTool adb patchTool aapt

Discussion:
Can't start virtual device: qemu libpixmin not found. Steps to reproduce the behavior: Genymotion any Android device it An android VM is started Here is log: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
propagatedBuildInputs = with python3Packages; [ colorama libtmux <ins> pyyaml </ins> ]; # No tests in archive

Discussion:
Steps to reproduce the behavior: This package is working in 23.11 I'm using as a stopgap measure. <!-- 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]:
please test
Change:
<ins> { stdenv, fetchFromGitHub, poco, openssl, SDL2, SDL2_mixer }: let craftos2-lua = fetchFromGitHub { owner = "MCJack123"; repo = "craftos2-lua"; rev = "v2.4.4"; sha256 = "1q63ki4sxx8bxaa6ag3xj153p7a8a12ivm0k33k935p41k6y2k64"; }; in stdenv.mkDerivation rec { pname = "craftos-pc"; version = "2.4.5"; src = fetchFromGitHub { owner = "MCJack123"; repo = "craftos2"; rev = "v${version}"; sha256 = "00a4p365krbdprlv4979d13mm3alhxgzzj3vqz2g67795plf64j4"; }; buildInputs = [ poco openssl SDL2 SDL2_mixer ]; preBuild = '' cp -R ${craftos2-lua}/* ./craftos2-lua/ chmod -R u+w ./craftos2-lua make -C craftos2-lua linux ''; installPhase = '' mkdir -p $out/bin DESTDIR=$out/bin make install ''; meta = with stdenv.lib; { description = "An implementation of the CraftOS-PC API written in C++ using SDL"; homepage = "https://www.craftos-pc.cc"; license = licenses.mit; platforms = platforms.linux; maintainers = [ maintainers.siraben ]; }; } </ins>

Discussion:
Project Description an emulator for the ComputerCraft minecraft mod allowing for easy development of lua programs Metadata homepage URL: https://www.craftos- source URL: license: mit platforms: linux
I have some code from user u/arienh4 on the nixos subreddit who helped me out with this. I have no idea how to do this so I don't know what it means but it might be helpful for people who do.
Change:
''; preConfigure = lib.optionalString stdenv.isDarwin ('' <del> cd src autoreconf -f -i -I m4 -I glm4 cd - </del> <ins> ( cd src autoreconf -f -i -I m4 -I glm4 ) </ins> '' + lib.concatMapStrings (x: '' <del> cd modules/${x} autoreconf -f -i -I ../../src -I ../../src/m4 -I ../../src/glm4 cd - </del> <ins> ( root="$PWD" cd modules/${x} autoreconf -f -i -I "$root/src" -I "$root/src/m4" -I "$root/src/glm4" ) </ins> '') withModules); configureFlags = [ "builddir" ]

Discussion:
Steps to reproduce the behavior: clisp Fail to build clisp on x86_64-darwin Please run and paste the result.
For context: afaik this was previously marked broken on all darwin systems, so this isn't a regression so much as "we could choose to mark x86_64-darwin broken again". It does work on aarch64-darwin.
Sorry, I wasn't clear. It fails at stage, where the derivation configures modules. I did succeed to build it with Is there any difference in the way to build the package in nixpkgs from this?
Sorry for removing the broken flag on x86_64 when I only tested aarch64.
This is one of those tooling issues IMO. I'm surprised we are allowed to merge PRs with broken builds like this without much noise from CI.
I've been taking a look at this and I think there are two problems: configure phase is failing early in nix build, but not when you run it yourself manually (try --it will get much further than a standard ). I'm not sure what the problem is here. you get past configure, actual build of clisp is still broken with all the currently enabled flags on x86_64-darwin. I have a fix for issue 1, which is cosmetic, but at least it makes the build in nixpkgs "fail consistently". :)
Fixed in .
I can confirm fixes it. Thanks everyone!
Change:
stdenv.mkDerivation rec { pname = "xpdf"; <del> version = "4.04"; </del> <ins> version = "4.05"; </ins> src = fetchzip { <del> url = "https://dl.xpdfreader.com/xpdf-${version}.tar.gz"; hash = "sha256-ujH9KDwFRjPIKwdMg79Mab9BfA2HooY5+2PESUgnGDY="; </del> <ins> urls = [ "https://dl.xpdfreader.com/xpdf-${version}.tar.gz" "https://dl.xpdfreader.com/old/xpdf-${version}.tar.gz" ]; hash = "sha256-LBxKSrXTdoulZDjPiyYMaJr63jFHHI+VCgVJx310i/w="; </ins> }; # Fix "No known features for CXX compiler", see

Discussion:
XPDF updated their version from 4.04 → 4.05 and seem to have broken the download URL to the older version. returns a 404, but works
Change:
vendorHash = "sha256-USkufc1dG4eyRfRJHSX4mVZHnvOc5onHenF98Aedac4="; <ins> nativeBuildInputs = [ installShellFiles ]; </ins> # This is a Go sub-module and cannot be built directly (e2e tests). excludedPackages = [ "./test" ];

Discussion:
After installation notation shell completion is not available. Steps to reproduce the behavior: notation completion Shell completion should be installed. N/A 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]:
Change:
postInstall = '' mkdir -p $lib cp -v $src/data/*.nix $lib <ins> wrapProgram $bin/bin/morph --prefix PATH : ${lib.makeBinPath [ openssh ]}; </ins> ''; outputs = [ "out" "bin" "lib" ];

Discussion:
Describe the bug Morph doesn't work without ssh installed/present on the system. To Reproduce Steps to reproduce the behavior: -shell --pure -p morph build something Expected behavior Morph builds something Screenshots Additional context Metadata NicksOhAss:~$ nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(root): channels(): nixpkgs: Maintainer information:
Change:
, buildWebExtension ? false }: let <del> version = "1.9.4"; gitHash = "9f79cc0"; </del> <ins> version = "1.9.5"; gitHash = "5bd10c8"; </ins> in buildNpmPackage rec { pname = "vencord";

Discussion:
Vencord settings at Discord doesn't appear when using the override on Steps to reproduce the behavior: Set up Discord with the override on Home Manager: Be able to access the Vencord options in the Discord settings. <img width="217" alt="image" src="" Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
What version of nixpkgs are you using? This was a Vencord bug that got fixed in recent versions of Vencord. The nixpkgs-unstable should work properly as far as I am aware.
As far as I know I've set up right the unstable in my flake:
I think it may be related with , this is how i'm setting it right now:
It is possible that it doesn't work on darwin :O
There is some sort of package that reports which nixpkgs channel was use to install it? Just to be sure is not an issue on my side, by the way works just fine so overriding is not the problem by itself. Edit: I tried to install a package only available at unstable and it work so it seems that the issue is with the package. I've also check if the commands that should run with the option activated worked and after extracting the ASAR file it's just like a vanilla discord install, I've tested it before letting Discord update itself so it seems it isn't related.
I just tested this on my work MacBook, and it seems to work fine. Is it possible that you still have a previous (non-Nix) Discord version that interferes here?
No luck so far, I've removed everything with Discord in its name that reported to not be in a nix related directory. The Discord logs doen't say anything related with Vencord. I'm in a Macbook Air M2 if this helps.
That could still be a locked before the fix. When was the last time you updated that Nixpkgs input in your flake lockfile, and/or what commit is listed in the lockfile entry for Nixpkgs?
I kinda have a similar issue with overriding Vencord, whenever I try to open the settings page it crashes with the following: ! I initially expected it to be an issue with openAsar but after disabling the open asar override the error persists.

It works as expected with the vencord override disabled.
With the latest Discord updates, Vencord is currently completely broken for reasons that are unrelated to Nix.
This is caused by a breaking change from upstream Discord — see This issue should be reserved for Nix-specific problems only. Also, has the issue ever been fixed on your end? If so, I think this issue could be closed
No luck so far installing the package through Home Manager using the nixpkgs master branch.
Change:
platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "f792fec194b611d5d79b93b6694876292c43bee55635d9422f885b6509eeb765"; </del> <ins> sha256 = "0rdpxq4nanw85x1djdanwnz46b19fr46kdlkkgbxa4dnjk0zx4pp"; </ins> type = "gem"; }; version = "0.10.1"; }; <del> fusuma-plugin-tap = { dependencies = ["fusuma"]; groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; sha256 = "0jlw08iw20fpykjglzj4c2fy3z13zsnmi63zbfpn0gmvs05869ys"; type = "gem"; }; version = "0.4.2"; }; </del> fusuma-plugin-wmctrl = { dependencies = ["fusuma"]; groups = ["default"]; platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "067939b2d8b99cf8fce43be40341cda3de3371596a8a4fb24eb13ca84c0bffe5"; </del> <ins> sha256 = "1rgz1d6ahg5i9sr4z2kab5qk7pm3rm0h7r1vwkygi75rv2r3jy86"; </ins> type = "gem"; }; version = "1.3.1";

Discussion:
The fusuma program in the package of the same name crashes when trying to run it. The breaking change causing this issue was made somewhere in the last 56 days: That's when I last updated this particular host, after which everything was still working fine. Steps to reproduce the behavior: "fusuma" package to run fusuma I expected fusuma to start running and be available for use. N/A Instead of displaying the expected behavior, the program crashes: In addition, if I clone the repo, then open a and run the cloned project in that nix-shell, that runs successfully unmodified on the same host. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks especially for the celerity of the fix!
Is there supposed to be a delay between this merge and availability updating? I can clearly see this PR is merged, but when I update my system the new version isn't in there.
Yes, see
One month later, I don't see the updated package. How long can this take ?
The update is already on master, but I don't think it's been backported yet. Are you on NixOS 23.11 instead of unstable?
Yes.
Backported in , should take a few days to land.
Many thanks for the commit !
Change:
}; patches = [ ./no-buildconfig-90.patch <ins> # There is a bug in Thunderbird 91 where add-ons are required # to be signed when the build is run with default settings. # https://bugzilla.mozilla.org/show_bug.cgi?id=1727113 # https://phabricator.services.mozilla.com/D124361 ./D124361.diff </ins> ]; meta = with lib; {

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:
, pythonOlder , fetchFromGitHub , pillow <del> , libX11 , libXcursor , libpng </del> <ins> , toml , numpy </ins> , python , pytestCheckHook }:

Discussion:
name: current version: desired version: maintainers: Please tag this issue in your PR. The is likely gone, and to generate cursors from scratch we probably also need to bump probably has breaking changes). Not sure if you wish to do that, or simply use the . AUR PKGBUILD:
Change:
option set to `relaxed` or `false`. */ <del> stdenv.mkDerivation rec { </del> <ins> stdenvNoCC.mkDerivation rec { </ins> pname = "iterm2"; <del> version = "3.4.0"; </del> <ins> version = "3.4.13"; </ins> src = fetchFromGitHub { owner = "gnachman"; repo = "iTerm2"; rev = "v${version}"; <del> sha256 = "09nhrmi25zxw3vp0wlib9kjr3p1j6am2zpwimdzqn0c80fq1lwvi"; </del> <ins> sha256 = "sha256-GOUdXBQCvM0oJ2/3zgKqDpfyCkHNwd1Qdopg5Mpyekg="; </ins> }; patches = [ ./disable_updates.patch ];

Discussion:
The iterm2 package () does not build on aarch64-darwin. I'm getting the following error message: Steps to reproduce the behavior: installing/building . the build failure. The package to build. n/a Complete logs are available here: <!-- 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. Maintainer information:
Hi Unfortunately, it was/is not possible to build item in a pure and reproducible way from source because it depends on your installed Xcode toolchain. It is therefore not an ideal candidate for nixpkgs and I didn't update the version of it either. Do you see any benefit in having iterm2 in nixpkgs compared to just downloading it from their website?
Hi thanks for packaging this! I generally have a slight preference to installing things via nix so that I can put them in my home-manager config, but at the end of the day it doesn't make a huge difference to me. It sounds like iterm2 is kind of a pain to package in general... Do you think it should be marked as broken or removed from nixpkgs?
Change:
inherit (pythonPackages) pyserial pygtk; }; <ins> browsh = callPackage ../applications/networking/browsers/browsh { }; </ins> chromium = callPackage ../applications/networking/browsers/chromium { channel = "stable"; pulseSupport = config.pulseaudio or true;

Discussion:
isn't yet available in Nixpkgs, which is a bummer since I wanted to check it out :). We'll probably need to go the "source" route (preferable anyway) since the "static binary" immediately starts looking for a dynamic linker/loader, here's a quick strace: Suggesting it's an unpacker of dynamically linked executables or something? Haven't investigated beyond the above :). Source looks like it's someone else's cup-of-tea :3.
Bump! I want to push this request!
er, re-bump? I'm interested in this too, would do it myself but I'm no patching ninja :)
You can probably use to build this as a derivation, you do not need to use the binary release. See the package being built in as an example of how to build it. I can probably package it up this weekend if no one has already done that.
I'd love that, largely because I can't find any docs on anywhere
sure I'll work on it today.
please try and let me know if it works for you.
Change:
, libffi , libiconv , libjpeg <ins> , libkrb5 </ins> , libpng , libsodium , libwebp

Discussion:
this package () is not available for any platforms. When I try to install the package from the shell To be available for popular platform like x86/amd64. arm64 If applicable, add screenshots to help explain your problem. Add any other context about the problem here. : Answered me by email. Merci :) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
For the context: I use the wrapper layer of Nix Package Manager and docker with
The extension is a core PHP extension and therefore, it is already available. On my side, I succeeded to test with my own project (loophp/nix-shell) by doing: a random file containing: in or . : in the same directory The thing is that is not in NixOS, if you want to enable it, you have to add it explicitly. The syntax to use is: Hope this helps.
Dear , I guess we can now close this issue ?
any idea why ?
No, but this is a good question, I guess or might help here.
So I did some digging into this, because it's a very good question. The reason for it not being enabled by default on darwin is because it wasn't enabled by default before we migrated to our modular build of PHP. The latest release branch before the modular build was 19.09 and here's the PHP definition from that time, where I have highlighted the line that we emulated by leaving it disabled after that big refactoring: -- so in 19.09 it was disabled on darwin. Inspecting that line further, the last time it was changed before that I linked it as of 19.09 was as part of a refactoring in July 2018: -- however, this commit actually didn't change the fact if it was enabled or not. So looking back ever further I found this, the commit authored in June 2016: That made a bunch of changes to the PHP definition, in which, one of the changes was to disable the imap extension on darwin. So I would assume that at that time, in June 2016, either as a dependency or the PHP extension itself actually didn't build on darwin, hence it was disabled to make PHP build at all on darwin.

Digging deeper: Here's the PR for that latest commit to fix the build back in 2016: And the corresponding issue: In the issue we can conclude that didn't build on darwin at that time. So it was a reasonable desicsion back then to disable that extension. Of course... now... 6 years later... this may not be a problem anymore and maybe we should revisit this :wink:
So now we have the PR merged to build on darwin, which sholud be a good first step to enable the imap extension:
Change:
license = licenses.asl20; platforms = platforms.linux ++ platforms.darwin; maintainers = [ maintainers.bjornfor ]; <ins> knownVulnerabilities = [ "CVE-2020-13949" ]; </ins> }; }

Discussion:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also:

, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also:
CVE details indicate that is vulnerable until version (included), which is the version we have in . Version seems to be the latest available: .
I'm actually wondering why this issue was created. We have thrift 0.13 in both unstable and 20.09. Closing and debugging my code...
I think the issue was rightfully created: it says INCLUDED!

, CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc
Change:
githubId = 508305; name = "Jaroslavas Pocepko"; }; <ins> vonfry = { email = "nixos@vonfry.name"; github = "Vonfry"; githubId = 3413119; name = "Vonfry"; }; </ins> vozz = { email = "oliver.huntuk@gmail.com"; name = "Oliver Hunt";

Discussion:
[Ant-Dracula] has moved to [Dracula]. [Dracula]: [Ant-Dracula]: Homepage: Repository:
Change:
license = licenses.gpl3Only; platforms = platforms.mesaPlatforms; maintainers = with maintainers; [ LunNova ]; <del> # python3Packages.pyqt-builder needs to be patched broken = stdenv.isDarwin; </del> }; }

Discussion:
Steps to reproduce the behavior: The regression is due to , which forgot to maintain the guard on darwin. While it is straightforward to fix the aarch64-darwin build, it isn't enough for x86_64-darwin due to . <!-- 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.
Change:
mv runfiles.bash.tmp tools/bash/runfiles/runfiles.bash patchShebangs . <del> # bazel reads its system bazelrc in /etc # override this path to a builtin one substituteInPlace  src/main/cpp/option_processor.cc  --replace BAZEL_SYSTEM_BAZELRC_PATH ""$out/etc/bazelrc"" </del> ''; in lib.optionalString stdenv.hostPlatform.isDarwin darwinPatches + genericPatches;

Discussion:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .