jiebi/CodeConvo huggingface dataset:
Change:
decls = # add location to sub-module options. map (m: mapSubOptions <del> (unifyOptionModule {inherit (m) key;}) </del> <ins> (unifyOptionModule {inherit (m) key;} name) </ins> m.options ) declarations;

Discussion:
On (), this fails: with Based on , maybe wants to know about this?
Unfortunately we don't always keep in a compilable state, but if you (or anyone else) is interested in fixing this, we would appreciate PRs fixing it up.
Is there some form of CI that would check whether it is compilable and maybe help identifying what broke it?
Not really. There is which will compile whenever someone sends a PR specifically for it. There is also , which runs builds for the various derivations in nixpkgs, but unfortunately it doesn't run all builds on all PRs (which would be too expensive). So most people don't have a good idea when different builds break. (I was planning on linking you to the GHCJS derivations on Hydra, but it is so slow, I'm not actually able to find a good link for you. If you go to and type in to the search box, you might get lucky and it will load for you. I believe you should be able to use this to go back in time and figure out when the GHCJS builds broke. Although Hydra's interface doesn't necessarily make this easy.) There are a few people who watch/review Haskell-related PRs here on nixpkgs, but we're often not too careful about the GHCJS builds. I don't think any of us use it. There are also a few other people who often send PRs to the Haskell infrastructure ( etc), but I am not sure if any of them rely on the GHCJS builds. I don't have a good solution for how to keep the GHCJS builds healthy, other than someone specifically keeping an eye on it. Although if all you're interested in is fixing the immediate build problem, you could try ing your way to the commit responsible for the breakage. I imagine the GHCJS builds have been working at least in the last couple months or so?
Oh, the Hydra search results just loaded. I think this is the GHCJS build on nixpkgs : It looks like this was the last successful build: This was the first failure build after this success: You might have to first look to see if that failure is the same one you're seeing locally. If it is, then you could try to figure out what commit caused it.

If that failure is not the same one you're seeing locally, then I'm not sure the best way to go about figuring out what broke it.
Thanks! Unfortunately, that was a weekend project, so probably won’t get to it until the next weekend where I will work on that… and pinning an old version of nixpkgs works around the problem nicely.
Are there any updates on this? I was hoping to upgrade to a newer nixpkgs to get cabal 3, but I don't know of a good working commit.
Ran into this as well. Found out that builds fine on the branch (commit currently). Hydra builds for it can be found here: Interestingly, neither of the commits on that pointed out - (the last successful one) and (the first failing one) - are ancestors of : I guess that means that contains some older packages. The version number of ghcjs is the same as in , though - 8.6.0.1.
FYI, published a PR that should resolve this issue:
Hopefully
Change:
doCheck = false; <del> nativeBuildInputs = [ pkgconfig which doxygen wxGTK ]; buildInputs = [ ncurses wxGTK.gtk ]; </del> <ins> nativeBuildInputs = [ pkgconfig which doxygen ] ++ (if stdenv.isDarwin then [ wxmac ] else [ wxGTK ]); buildInputs = [ ncurses libintl ] ++ (if stdenv.isDarwin then [ AudioToolbox Carbon Cocoa CoreFoundation IOKit OpenGL ] else [ wxGTK.gtk ] ); </ins> DOXYGEN = "${doxygen}/bin/doxygen";

Discussion:
Describe the bug wxPython40, , does not build there likely because it uses wxGTK rather than this prevents kicad from being built on darwin To Reproduce Steps to reproduce the behavior: darwin, Expected behavior wxPython40 to build on darwin and be usable by kicad there Additional context i maintain the kicad package and Notify maintainers while there are no listed maintainers for this package it was initially contributed by (if you already investigated after the kicad PR ping, nothing relevant changed since) and has a fair amount of contributions by Maintainer information:
Hi I don't have/use mac but happy to answer any wxPython questions as I can
I'm experiencing the same issue with Linux, using .
likely a different issue. Stacktrace? What nixpkgs version / commit?
The as of this writing. Here's the output I'm seeing. <details<summarybuild log</summary</detailsIt looks like pkg-config is giving an old version of GTK+?
please use your failure seems the same as which i closed because it's fixed in the branch by and i can confirm at least starts building there (it's still going...) i'm not sure when this fix will get to ...
nice! didn't know about the details tag. Ok yeah that looks like my issue, thanks for pointing me in that direction.
I can reproduce this on 10.14.6. My best take so far was to use and adapt other Darwin requirements. <details<summarydiff against master</summary</detailsUnfortunately it does not build with the same errors as for the .
Bumped to 3.0.5.1, to its , and it builds! was set, but no dependency specified. That's what caused the missing symbols. <details<summaryworking diff</summary</detailsI'm not even sure why this works at all. claims they build from a submodule, but obviously in this setup we take whatever is supplied through . To be pedantic, 4.0.7 is supposed use some specific instead of a release, as you can . That commit is after* 3.0.4 and shortly before 3.0.5. I only skimmed the , but it sounds and looks like backwards-compatible bug fixes. Opinions on how to proceed?

If we follow upstream and choose the intermediate revision, what to specify as the package version?
i've kinda given up on stuff, at least until the next release which i hope will either be built based on a release or be compatible with the latest release (i have no reason to believe this would be the case though) if you have a diff that fixes a package, i recommend you make a PR 4.0.7 seems to work with the 3.0.4, it seems reasonable to assume the same would be true for 3.0.4
Change:
<del> { stdenv, fetchFromGitHub, pkgconfig, pango, cairo, libGLU, lv2 }: stdenv.mkDerivation rec { pname = "avldrums.lv2"; version = "0.4.0"; src = fetchFromGitHub { owner = "x42"; repo = pname; rev = "v${version}"; sha256 = "1z70rcq6z3gkb4fm8dm9hs31bslwr97zdh2n012fzki9b9rdj5qv"; fetchSubmodules = true; }; installFlags = [ "PREFIX=$(out)" ]; nativeBuildInputs = [ pkgconfig ]; buildInputs = [ pango cairo libGLU lv2 ]; meta = with stdenv.lib; { description = "Dedicated AVLDrumkits LV2 Plugin"; homepage    = http://x42-plugins.com/x42/x42-avldrums; license     = licenses.gpl2; maintainers = [ maintainers.magnetophon ]; platforms   = [ "i686-linux" "x86_64-linux" ]; }; } </del>

Discussion:
Recently a second version of avldrums got merged: We already had
cc
How many of these kind of plugins do we have? Does it make sense to put them in a package set?
What do you mean by these kind of plugins? LV2 in general? Might make sense. Not sure what the advantages and disadvantages are. avldrums? There is only one, but it's packaged twice. (just in case you missed that). :)
Yes, lv2 in general. We should do this
So by package set you mean just move them next to each other in all-packages? BTW, not all of the above are plugins: lv2: the library lv2bm: an lv2 benchmarker faust2lv2: a compiler to make lv2s with There are also more lv2 plugins in nixpkgs.
Unfortunately x42 stuff has two names, sometimes distantly related (x42-autotune is aka fat1.lv2). It seems that x42 names are better because they are more recognizable (as belonging to x42-), they are used in URLs (https://x42-) and as the names of packages (https://x42-). It would be useful to be able to find all packaged lv2 plugins at a glance. However, since some lv2 plugins come with a standalone application, sometimes it will be difficult to decide whether a package should be classified as a plugin or not. (I would classify x42-plugins as plugins despite their programs in bin/, but qmidiarp as a non-plugin despite its lib/lv2/.)
I propose the same approach as in Python. In case its plugins, put them in the plugin set. In case its only application, put them in top-level, if both, put them in plugins and offer a top-level reference.
I agree it would be useful to be able to find all packaged lv2 plugins at a glance.
OK. I would propose to name the package set audioPlugins and put the definitions in applications/audio/plugins/ . They should comprise DAW plugins (lv2, ladspa, dssi, vst), but not e.g. media player plugins (gst-plugins-good).

It does not seem useful to subdivide plugins further, because audio hosts support many types of plugins (Ardour and Carla support lv2, ladspa, vst) and some packages provide many types of plugins at once (zam-plugins has lv2, ladspa, vst; wolf-shaper has lv2, dssi, vst).
I'm not familiar with DAWs but that sounds reasonable! Maybe then so its clear its not about and such?
Change:
google-pasta wrapt tensorflow-estimator_2 <del> tensorflow-tensorboard </del> <ins> tensorflow-tensorboard_2 </ins> keras-applications keras-preprocessing ] ++ lib.optional (!isPy3k) mock

Discussion:
Describe the bug Trying to build a shell with python 3.7 and tensorflow, yields the following build error: This is similar to , although this issue is for the old tensorflow 1.15.0 version. To Reproduce Steps to reproduce the behavior: the following file: Expected behavior Tensorflow 2.1.0 is installed correctly. Screenshots n / a Additional context n / a Metadata system: host os: multi-user?: sandbox: version: channels(da): channels(root): nixpkgs: Maintainer information:
Change:
# incompatibleKernelVersion = "4.19"; # this package should point to a version / git revision compatible with the latest kernel release <del> version = "0.8.4"; </del> <ins> version = "2.0.0-rc1"; </ins> <del> sha256 = "1hl4n900d24gl4vd65qdzq4m62b7bpvckldazcbd1xqcn8xhi6wp"; </del> <ins> sha256 = "0d1m5zwgqzfwbscvb60zvzkjgl5nkbvas22vjsyci3xygz0qwjsb"; </ins> isUnstable = true; }; }

Discussion:
Hello! I'd like to know whether, as the title says, it would be possible to update the ZFS derivation to the latest release candidate, , as it allows for compression, and I am exceptionally eager to try it out; if not, how could I update the derivation in my own configuration? Thank you kindly for your consideration on the matter!
Crosspost:
Change:
, sigtool, jansson, harfbuzz, sqlite, nixosTests , dontRecurseIntoAttrs, emacsPackagesFor , libgccjit, targetPlatform, makeWrapper # native-comp params <ins> , fetchFromSavannah </ins> , systemd ? null , withX ? !stdenv.isDarwin , withNS ? stdenv.isDarwin

Discussion:
The issue is what the title says. By half, I mean and for my previously used from emacs-overlay to your system the eln cache in your home, e.g. to open emacs for the manual for by and inputing the eln cache in your home: , you will find together other eln cache. I think this is a bug since is builtin for emacs and it's eln cache should be distributed together with . Uses of will not need to native-compile builtin libraries themselves. does distributed together with from emacs-overlay I used before. It's . might be related to the bump of 28 , so
The difference between the two versions is that one is built from the tarball, while the other is built from Git. The tarball includes byte-compiled () files but not native-compiled () files. The build notices the files and does not rebuild them, but native-compilation is a side-effect of byte-compilation and so the files aren't built either. (Almost all of the files you see for the new version are trampolines, there are only 3 non-trampoline files.)
ideally we'd run , which is the expected way of deleting such things (or perhaps even ). But the tarball only has a , so we'd need to run , then , then again, which is super ugly. Hopefully deleting the files the naïve way is enough?
I think maybe we should just skip the tarball entirely and fetch it from git instead.
There are other side-effects caused by skipping the tarball. This claims, for example, that bootstrapping is only expected to happen to emacs developers. Part of bootstrapping is converting the Japanese input method dictionaries, and this takes some amount of time. They're in the tarball at , but are absent in the git checkout.
That's a good point, I would still rather inflate build times a bit and exercise bootstrapping as a part of our regular build though to completely avoid these types of issues.
I'm hesitant about building things in a way that upstream doesn't expect, unless necessary to adapt for nixpkgs. For a related example, using the repo instead of the tar distribution for Ruby caused a subtle problem where the commit hash was not propagated, which broke the bootsnap gem's cache invalidation (fixed in , by using the tarball).

The real question here, I think, is how upstream expects native compilation to be used if their tarball doesn't support it.
Change:
rust-code-analysis = callPackage ../development/tools/rust-code-analysis { }; <ins> rust-motd = callPackage ../tools/misc/rust-motd { inherit (darwin.apple_sdk.frameworks) Security; }; </ins> rust-petname = callPackage ../tools/text/rust-petname { }; rustcat = callPackage ../tools/networking/rustcat {

Discussion:
Project description A rust program that can do dynamic motd generation with no dependencies Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... MIT platforms: unix, linux, darwin, ... linux, UNIX, darwin. I would love to learn to package something like this if you all are willing to teach me. I would love to contribute more packages when I understand the process a bit better.
Change:
<ins> { lib, fetchFromGitHub, python3Packages, }: let version = "0.2.0"; in python3Packages.buildPythonPackage { pname = "datatrove"; inherit version; pyproject = true; src = fetchFromGitHub { owner = "huggingface"; repo = "datatrove"; rev = "refs/tags/v${version}"; hash = "sha256-2NJja2yWeHOgo1pCuwHN6SgYnsimuZdK0jE8ucTH4r8="; }; nativeBuildInputs = with python3Packages; [ setuptools ]; propagatedBuildInputs = with python3Packages; [ dill fsspec huggingface-hub tokenizers humanize loguru multiprocess numpy rich ]; nativeCheckInputs = with python3Packages; [ pytestCheckHook ]; dependencies = with python3Packages; [ boto3 fasteners huggingface-hub moto nltk s3fs xxhash ]; disabledTestPaths = [ "tests/executor/test_local.py" "tests/pipeline/test_filters.py" "tests/pipeline/test_bloom_filter.py" "tests/pipeline/test_minhash.py" "tests/pipeline/test_sentence_deduplication.py" "tests/pipeline/test_tokenization.py" "tests/pipeline/test_exact_substrings.py" ]; pythonImportsCheck = [ "datatrove" ]; meta = { description = "Set of platform-agnostic customizable pipeline processing blocks for data processing"; homepage = "https://github.com/huggingface/datatrove"; changelog = "https://github.com/huggingface/datatrove/releases/tag/v${version}"; license = lib.licenses.asl20; maintainers = with lib.maintainers; [ luftmensch-luftmensch ]; platforms = lib.platforms.all; }; } </ins>

Discussion:
Project description From the repo's readme: Metadata homepage URL: source URL: license: apache 2.0 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<ins> { lib , stdenv , fetchFromGitHub , installShellFiles }: stdenv.mkDerivation rec { pname = "pyenv"; version = "2.3.21"; src = fetchFromGitHub { owner = "pyenv"; repo = "pyenv"; rev = "refs/tags/v${version}"; hash = "sha256-+rMkbrRSQBHX9qdifIpdLmQ8Uk39ott0xyJTD/mb+9w="; }; postPatch = '' patchShebangs --build src/configure ''; nativeBuildInputs = [ installShellFiles ]; configureScript = "src/configure"; makeFlags = ["-C" "src"]; installPhase = '' runHook preInstall mkdir -p "$out" cp -R bin "$out/bin" cp -R libexec "$out/libexec" cp -R plugins "$out/plugins" runHook postInstall ''; postInstall = '' installManPage man/man1/pyenv.1 installShellCompletion completions/pyenv.{bash,fish,zsh} ''; meta = with lib; { description = "Simple Python version management"; homepage = "https://github.com/pyenv/pyenv"; changelog = "https://github.com/pyenv/pyenv/blob/${src.rev}/CHANGELOG.md"; license = licenses.mit; maintainers = with maintainers; [ tjni ]; platforms = platforms.all; }; } </ins>

Discussion:
Project description pyenv lets you easily switch between multiple versions of Python. It's simple, unobtrusive, and follows the UNIX tradition of single-purpose tools that do one thing well. It is a critical application for Python development. Metadata homepage URL: source URL: license: MIT platforms: ALL
Change:
configFile = lib.optionalString (conf != null) (builtins.toFile "nnn.h" conf); preBuild = lib.optionalString (conf != null) "cp ${configFile} src/nnn.h"; <del> nativeBuildInputs = [ pkg-config makeWrapper ]; </del> <ins> nativeBuildInputs = [ installShellFiles makeWrapper pkg-config ]; </ins> buildInputs = [ readline ncurses ]; <del> makeFlags = [ "PREFIX=$(out)" ] </del> <ins> makeFlags = [ "PREFIX=${placeholder "out"}" ] </ins> ++ lib.optional withIcons [ "O_ICONS=1" ] ++ lib.optional withNerdIcons [ "O_NERD=1" ]; <del> # shell completions </del> <ins> binPath = lib.makeBinPath [ file which ]; </ins> postInstall = '' <del> install -Dm555 misc/auto-completion/bash/nnn-completion.bash $out/share/bash-completion/completions/nnn.bash install -Dm555 misc/auto-completion/zsh/_nnn -t $out/share/zsh/site-functions install -Dm555 misc/auto-completion/fish/nnn.fish -t $out/share/fish/vendor_completions.d </del> <ins> installShellCompletion --bash --name nnn.bash misc/auto-completion/bash/nnn-completion.bash installShellCompletion --fish misc/auto-completion/fish/nnn.fish installShellCompletion --zsh misc/auto-completion/zsh/_nnn </ins> <del> wrapProgram $out/bin/nnn  --prefix PATH : ${lib.makeBinPath [ archivemount atool fzf libarchive rclone sshfs unzip vlock ]} </del> <ins> wrapProgram $out/bin/nnn --prefix PATH : "$binPath" </ins> ''; meta = with lib; {

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.
Change:
{ stdenv, callPackage, fetchurl, makeDesktopItem, makeWrapper, patchelf , coreutils, gnugrep, which, git, python, unzip, p7zip <del> , androidsdk, jdk, oraclejdk8 </del> <ins> , androidsdk, jdk </ins> }: assert stdenv.isLinux;

Discussion:
Right now the IntelliJ derivation hardcodes oraclejdk8, and AFAICT the only way to override this choice is by overriding oraclejdk8 itself: (I have tried and with no effect.) Can we make this overridable somehow? (FWIW, I've had no problems with 15 and 15 EAP under openjdk8, although I'm getting redraw artifacts with 16 EAP.) cc
It was just recently changed away from that due to Idea having some bug with and not seeming very open to dealing with it. I can't find the ticket right now...
Oh
Okay, found the root cause of this bug. The crucial line is the following in (in openjdk): This checks that is indeed in , and guess what this returns with our symlink maze... As a temporary workaround you can set as an extra environment variable. This manages to hit the only special case in which doesn't have this check, and then intellij works fine with openjdk. Maybe I can draft a PR to fix this tomorrow.
Since the PR is merged, I assume this issue was just forgotten.
Change:
libXScrnSaver libappindicator-gtk3 libdbusmenu <ins> wayland </ins> ]; installPhase = ''

Discussion:
Can't launch discordcanary with NIXOSOZONEWL=1 Steps to reproduce the behavior: NIXOSOZONEWL = "1"; in environment.variables discordcanary with Discord should open without any errors I got this error Please run and paste the result.
Library should be from
Please try with
Change:
home = "/var/lib/lightdm"; group = "lightdm"; uid = config.ids.uids.lightdm; <ins> shell = pkgs.bash; </ins> }; systemd.tmpfiles.rules = [

Discussion:
I am installing NixOS on a new laptop and I decided to try elementary. Well, it doesn’t quite work yet (still looking into the issue), but I already noticed something minor and thought I'd report it before I forgot. I don’t have the exact logs yet (because I’m just trying to get the laptop to work), but the idea is that I am trying to adjust screen brightness from the greeter and it does nothing. In there is a whole bunch of errors from which says: I think the idea here is that lightdm runs this helper as a login shell, so it needs to be listed in . Therefore, my guess would be to try to add this long path to in the pantheon module. Notify maintainers cc I guess
See
Thanks for the link. I went through that discussion, and it looks like the problem in that case was that the they had zsh configured as the user’s shell, but it was not to – this probably worked fine most of the time but Polkit would not allows anything to be done with the variable set to zsh, and it was set because the call was happening in the user’s session with the environment configured. I’m not sure I understand how this can be related here, because I am talking about the greeter, where there is no user session yet. (My user has zsh configured as the shell indeed, but it is present in .)
That said, I am trying to figure out what the variable is set to in the context of the greeter, but I am having trouble with that, since a) Vala is something completely new to me; b) looks like this is all handled by the GNOME Settings Daemon and the greeter just makes a DBus call to it, so I am having trouble figuring out how Polkit gets involved at all.
I believe the greeter it still could be the same issue, because it will run with the shell of the user. And I can see in the module that no shell is set, so it's the default which I don't think will be in . Do you think you could try setting ?
The log is still spammed with tens of: unfortunately, I’m wondering if there could be a way to silence these...
Everytime you press the key to change brightness it turns into a call for gsd-backlight-helper to change brightness.

In the latest g-s-d (we use a fork of g-s-d for pantheon so everything still works) this is done with systemd so all that logging would be gone in later versions. I think gets logged default or something.