jiebi/CodeConvo huggingface dataset:
Change:
<ins> { lib, mkCoqDerivation, coq, interval, compcert, flocq, bignums, version ? null }: with lib; mkCoqDerivation { pname = "vcfloat"; owner = "VeriNum"; inherit version; defaultVersion = with versions; switch coq.coq-version [ { case = range "8.16" "8.17"; out = "2.1.1"; } ] null; release."2.1.1".sha256 = "sha256-bd/XSQhyFUAnSm2bhZEZBWB6l4/Ptlm9JrWu6w9BOpw="; releaseRev = v: "v${v}"; propagatedBuildInputs = [ interval compcert flocq bignums ]; meta = { description = "A tool for Coq proofs about floating-point round-off error"; maintainers = with maintainers; [ quinn-dougherty ]; license = licenses.lgpl3Plus; }; } </ins>

Discussion:
Project description VCFloat: A Unified Coq Framework for Verifying C Programs with Floating-Point Computations Metadata homepage URL: source URL: license: LGPL platforms: <uncertain limitations here
Change:
enterprisePolicies = { <del> policies = lib.optionalAttrs usesNixExtensions  { </del> <ins> policies = { </ins> DisableAppUpdate = true; } // lib.optionalAttrs usesNixExtensions {

Discussion:
A clear and concise description of what the bug is. firefox-bin just tried to update itself. is empty: <!-- 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.
tracing policiesJson makes Nix (2.6.1) do something on a CPU for a while and then segfault... Repl works fine. Weird. The problem seems to be in the wrapper, -unwrapped is fine!.
is the problem
While contains , , otherwise they default to . I use to work around this because it appeared to be intentional but the default should probably be changed - I'm not sure why it's optional in the wrapper, that seems to have been introduced in for some reason?
Change:
#Adapted from #https://github.com/rycee/home-manager/blob/2c07829be2bcae55e04997b19719ff902a44016d/home-manager/default.nix <del> { bash, coreutils, findutils, gnused, less, gettext, nixos-option, lib, stdenv, makeWrapper, fetchFromGitHub }: </del> <ins> { bash, coreutils, findutils, gnused, less, ncurses, gettext, nixos-option, lib, stdenv, makeWrapper, fetchFromGitHub }: </ins> stdenv.mkDerivation rec {

Discussion:
I am new to Nix, but I am pretty sure there is a dependency missing. Run Docker container: Install home-manager: Execute home-manager: Install ncurses: The Shell script itself uses the tput command.
Change:
name = "soh"; icon = "soh"; exec = "soh"; <ins> comment = finalAttrs.meta.description; </ins> genericName = "Ship of Harkinian"; desktopName = "soh"; categories = [ "Game" ]; }) ]; <del> meta = with lib; { </del> <ins> meta = { </ins> homepage = "https://github.com/HarbourMasters/Shipwright"; description = "A PC port of Ocarina of Time with modern controls, widescreen, high-resolution, and more"; <del> longDescription = '' An PC port of Ocarina of Time with modern controls, widescreen, high-resolution and more, based off of decompilation. Note that you must supply an OoT rom yourself to use this package because propietary assets are extracted from it. You can change the game variant like this: shipwright.override { oot.enable = false; ootMq.enable = true } The default ROM variants for Oot and OotMq are debug and debug-mq respectively. If you have a pal-gc rom, you should override like this: shipwright.override { oot = { enable = true; variant = "pal-gc"; rom = path/to/oot-pal-gc.z64; } } The supported Oot variants are: - debug: Ocarina of Time Debug PAL GC (not Master Quest) - pal-gc: Ocarina of Time PAL GameCube (may lead to crashes and instability) The supported OotMq variants are: - debug-mq: Ocarina of Time Debug PAL GC MQ (Dungeons will be Master Quest) - debug-mq-alt: Alternate ROM, not produced by decompilation. ''; </del> mainProgram = "soh"; platforms = [ "x86_64-linux" ]; <del> maintainers = with maintainers; [ ivar j0lol ]; license = with licenses; [ </del> <ins> maintainers = with lib.maintainers; [ ivar j0lol ]; license = with lib.licenses; [ </ins> # OTRExporter, OTRGui, ZAPDTR, libultraship mit # Ship of Harkinian itself unfree ]; }; <del> } </del> <ins> }) </ins>

Discussion:
Package name: shipwright Latest released version: 8.0.4 <!-- Search your package here: --- Current version on the unstable channel: 7.1.1 Current version on the stable/release channel: 7.0.2 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers I tried updating myself and found 8.0.4 fails building with error I bisected to upstream commit and the file but I'm not sure how to resolve right now. <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
libmediainfo libraw libsodium <del> libtool </del> libuv libzen qtbase

Discussion:
Describe the bug Latest MEGAsync app fails to start (Segmentation fault), probably because of . Not sure if it is NixOS related or just a MEGAsync bug. To Reproduce Steps to reproduce the behavior: it fault Expected behavior No crash Additional context Crash dump: 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 Maintainer information:
Yep I have this too. Actually the most recent commit version doesn't open at all, just dumps core - but the previous commit before that () does open and reopens on startup and everything fine, despite giving me the segmentation fault when I open it manually. <details<summaryCrashdump</summary
Same for me. Reported upstream: Bumping the version to does not help. It is still usable for me on 20.09 stable with this overlay:
Does anyone know how to specify an older version of cryptopp, as a stopgap until this is fixed upstream? I'm in desperate need of getting Megasync to work again. The overlay above isn't working for me on Unstable.
can't you just use michojel's overlay above, or an older version of the megasync package entirely? The latter is what I'm doing rn, just stick this in your : Which pins commit (which still uses megasync 4.3.5.0)
Looks like 4.4.0.0 addressed the issues. Works for me at least. See
Change:
with lib; let <ins> json = pkgs.formats.json { }; </ins> cfg = config.services.prometheus; workingDir = "/var/lib/" + cfg.stateDir;

Discussion:
I am currently struggling with the ability to configure a valid federation between two Prometheus instances. Instance A is my Prometheus master and import all scraped values from Instance B with a specific label. The current module implementation does not result in a valid federation configuration (or i dont get it how to properly escape it). A minimal setup for a federation is The problematic part is here the field. From the match Params has to contain a line like . The specific params from does define the type as a attribute list of strings, so my example should result in the desired result. Please notice that the quotes around the LabelValue are important in that case otherwise it does not result in a valid request to a federation instance. Steps to reproduce the behavior: example code form above generated configuration file for missing quotes. (Optional) Have another Prometheus instance set up and data available to be loaded and verity that no values can be imported The generated config from aboves example is Which is missing the quotes, which are required to be a valid configuration. The actual error the server may get on loading the data could be something like that (I did just fill in the params as GET like the documentation of Prometheus explains how the federation values are loaded) A user is able to configure a federation via declarative scrapeConfig attribute. The expected configuration for above's example is I also tried other combinations like resulting in an escaped value , which is also obvious wrong. I already tried to analyze the issue to some point. At is the actual writing of the file. When i do something like with my flake (tank is the hostname of the Prometheus master) That should be the minimal part of the config writing without the prior validation logic and results in the expected result So my assumption is that it gets somewhere on validation broken and that is here: Sadly i am a newbie on nix language and not able to bring that to a nix repl to play around. But as the plain write operation does result in a valid configuration i am at least optimistic that i do not do things wrong. As workaround i can use configText attribute to bring in again the fixed generated config. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something.

-- (I have @ the last editor of the file and the persons which edited the section i assume may causes the issue, as the module has no meta tag) Please run and paste the result.
The issue do occur due echoing the content that way . This removed the qoutes. There is a nice tool in which handles that situation, but should basically do the same as it was done before.
Change:
"-Dwpe=disabled" # required `wpe-webkit` library not packaged in nixpkgs as of writing "-Dzxing=disabled" # required `zxing-cpp` library not packaged in nixpkgs as of writing ] <ins> ++ optionals (!stdenv.isLinux) [ "-Dva=disabled" # see comment on `libva` in `buildInputs` ] </ins> ++ optionals stdenv.isDarwin [ "-Dbluez=disabled" "-Dchromaprint=disabled"

Discussion:
Describe the bug Building gst-plugins-bad-1.18.0 errors out on Darwin with: To Reproduce On master: Expected behavior should compile Additional context Version bump from 1.16.2 -1.18.0 in includes new dependencies libmicrodns and libva that might be incompatible for macOS Notify maintainers Metadata
has tags on the right so chances are that isn't true and that it works on Darwin. Could you try in there?
leads to continuing down this rabbit hole leads to libpciaccess is pulled in by libdrm, which is pulled in by libva, which is pulled in by gst-plugins-bad as mentioned above. Since the cited attribute is in I don't suppose it is feasible for Darwin.
Thanks, I hadn't found that override, that's what I needed to know. This might fix it, give it a try: PR
build continues as expected, yet leads to
gist of meson-
Probably needs in on Darwin, looking at:
so disabling v4l2codecs solved the problem. Complete diff:
just noticed your comment. Yes, indeed, that was the last piece. Thx.
Change:
stdenv.mkDerivation rec { pname = "gasket"; <del> version = "1.0-18"; </del> <ins> version = "1.0-18-unstable-2023-09-05"; </ins> src = fetchFromGitHub { owner = "google"; repo = "gasket-driver"; <del> rev = "97aeba584efd18983850c36dcf7384b0185284b3"; sha256 = "pJwrrI7jVKFts4+bl2xmPIAD01VKFta2SRuElerQnTo="; </del> <ins> rev = "09385d485812088e04a98a6e1227bf92663e0b59"; sha256 = "fcnqCBh04e+w8g079JyuyY2RPu34M+/X+Q8ObE+42i4="; </ins> }; makeFlags = [

Discussion:
There is a issue when trying to add this ( ) to the boot.extraModulePackages list. As noted by clever in irc "all out-of-tree modules should be in packagesFor, which lets you just boot.extraModulePackages = [ ];" Steps to reproduce the behavior: boot.extraModulePackages = [ ( { kernel = ; }) ]; is what is needed but boot.extraModulePackages = [ ]; is the expected. boot.extraModulePackages = [ ]; in the hardware- This is needed to get the gasket kernel module so that /dev/apex_X devices show up under /dev/ Please run and paste the result.
I think is supposed to solve this? I just don't know how to get it unstuck.
I used this for a work-around:
There's a new patch that allows building with 6.4 kernels as well.
A quick workaround to get this to build on . This includes the kernel override discussed above, and uses a later version of the upstream that includes support for kernels = 6.4. Upstream does not seem to add version numbers very frequently, so this uses the first 6 charaters of the git revision as version.
Change:
+} #endif diff --git a/src/funopen.c b/src/funopen.c <del> index 1e05c7e..ed8ce85 100644 </del> <ins> index 1e05c7e..75e61ea 100644 </ins> --- a/src/funopen.c +++ b/src/funopen.c <del> @@ -137,7 +137,7 @@ funopen(const void *cookie, return fopencookie(cookiewrap, mode, funcswrap); } -#elif defined(__MUSL__) +#elif defined(__MUSL__) || defined(darwin) || defined(__APPLE__) || defined(MACOSX) /* * This is unimplementable on musl based systems, and upstream has stated </del> <ins> @@ -143,6 +143,7 @@ funopen(const void *cookie, </ins> * they will not add the needed support to implement it. Just ignore this <ins> * interface there, as it has never been provided anyway. */ +#elif defined(darwin) || defined(__APPLE__) || defined(MACOSX) #else #error "Function funopen() needs to be ported or disabled." #endif </ins> diff --git a/src/getentropy.c b/src/getentropy.c index 3f11a1e..8a23a07 100644 --- a/src/getentropy.c

Discussion:
cc system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
Thanks!

Not sure how difficult it'd be to fix this, but thought I'd note it somewhere. We recently bumped to 0.8.5 but I don't see any reason that would make the patch apply again (although I can't confirm this myself :)). If it can't be resolved reasonably perhaps the patch should be dropped and "darwin" removed from ? EDIT: Looks like libbsd has a separate "port" for OSX: which I've filed an issue on (like was done previously, apparently): Try to build libbsd on Darwin; look at Hydra/Travis build failures. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
Yeah, I have just been manually updating the patch since v0.8.3. The "correct" thing to do would be to get the patch applied upstream in libbsd. Perhaps freedesktop doesn't want it though. /cc
Change:
"--with-tclsh=${tcl}/bin/tclsh" "--with-tlib=ncurses" "--with-compiledby=Nix" <ins> "LDFLAGS=-headerpad_max_install_names" </ins> ]; makeFlags = ''PREFIX=$(out) CPPFLAGS="-Wno-error"'';

Discussion:
Describe the bug The latest macvim fails to install with a build error like below I think this change is the cause: The previous version builds fine. To Reproduce the channel to the latest one. or update macvim: or will see the error back to the previous generation: works fine Expected behavior Should install/update fine. Screenshots N/A Additional context macOS 10.14.6 (18G87) Metadata Please run and paste the result. Maintainer information:
cc:
Huh, it builds on my 10.14.6 machine, I wonder what the difference is. Also looking through the build output right now I see on the link command for MacVim. Did you customize macvim, or just build it as-is?
I guess the link command for the binary doesn't include , just the one for .
I don't have any customizations.
Ok I’ll look into adding the right flag to the Vim link step when I can.
Can you test and let me know if that fixes it?
Will do but I'm quite new to nix and don't know how to apply that change to my local nix env. Any pointers?
Normally I'd suggest using to build it, but that builds with the sandbox and macvim can't build with the full sandbox (it requires the sandbox to be off or in ). Given that, what you can do is just check out the PR branch. If you have a git checkout of nixpkgs this can be done with . Then you can run to build macvim from that checkout. If this succeeds it'll create a symlink in the current directory that contains the build results. You could in theory install this into your environment too if you like, with .
Can do or
worked. Thanks, & !
Thank you for testing. I will merge the fix now.
Change:
<del> { stdenv, fetchurl, libuuid }: stdenv.mkDerivation rec { name = "zeromq-3.2.5"; src = fetchurl { url = "http://download.zeromq.org/${name}.tar.gz"; sha256 = "0911r7q4i1x9gnfinj39vx08fnz59mf05vl75zdkws36lib3wr89"; }; buildInputs = [ libuuid ]; doCheck = false; # fails all the tests (ctest) meta = with stdenv.lib; { branch = "3"; homepage = "http://www.zeromq.org"; description = "The Intelligent Transport Layer"; license = licenses.gpl3; platforms = platforms.all; }; } </del>

Discussion:
, (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
According to this comment , should not be affected. Nontheless, this is a very old version and there are only two packages depends on it: rzmq (apparently supports 4.x but is broken since 2016) jzmq (support 3.x and looks unmaintained) jzmq is only needed by apache stom but the dependecy as since been dropped: see can you update apache storm so we can get rid of jzmq?
Change:
serviceConfig = { ExecStart = '' <del> ${cfg.alerts.package}/bin/consul-alerts start  </del> <ins> ${cfg.alerts.package.bin}/bin/consul-alerts start  </ins> --alert-addr=${cfg.alerts.listenAddr}  --consul-addr=${cfg.alerts.consulAddr}  ${optionalString cfg.alerts.watchChecks "--watch-checks"} 

Discussion:
NixOS services that depend on binaries are now broken (eg ) after This is because the attribute path for binaries has now changed. For example should now be .
I can do it tomorrow.
Change:
(mkRemovedOptionModule [ "services" "openvpn" "enable" ]) (mkRemovedOptionModule [ "services" "printing" "cupsFilesConf" ]) (mkRemovedOptionModule [ "services" "printing" "cupsdConf" ]) <ins> (mkRemovedOptionModule [ "services" "xserver" "startGnuPGAgent" ]) </ins> ]; }

Discussion:
Commit from updated the default version of the GNU Privacy Guard a.k.a. GPG to version 2.1. Unfortunately, this update broke the gpg-related tests of , , apparently because there is some subtle change in the behavior of the GPG 1.x compatibility layer (git-annex relies on rather than using gpg2 directly). To remedy that issue, I fixed to use version 2.0 in . This is no good solution, unfortunately, because now people who rely on `gnupg1' end up having a version of GnuPG 2.0 in their profile that cannot talk to the gpg-agent from version 2.1, which happens to be the one that's installed in the system by default. In it's current state, gpg1 does not work reliably in NIxOS. To work around this issue, I would suggest that we revert to version 2.0 until we've had time to figure out what exactly has changed between versions 2.1 and 2.0 and why this affects .
FYI: Another thing I came across, due to a broken clawsmail pgp, was that the handling of gpg-agent differs from version 2.0 . GnuPG 2.1 do not use GPGAGENTINFO anymore. Instead it search for the gpg-agent socket in
For now at least, setting GPGAGENTINFO to $ seems to make claws-mail work.
Change:
license = licenses.asl20; platforms = platforms.linux ++ platforms.darwin; maintainers = [ maintainers.bjornfor ]; <ins> knownVulnerabilities = [ "CVE-2018-1320" "CVE-2018-11798" "CVE-2019-0205" "CVE-2019-0210" "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:
<del> { lib, fetchurl, alsa-lib, fluidsynth, libjack2, autoconf, pkg-config , mkDerivation, qtbase, qttools, qtx11extras </del> <ins> { lib, stdenv, fetchurl, alsa-lib, fluidsynth, libjack2, cmake, pkg-config , qtbase, qttools, qtx11extras, wrapQtAppsHook </ins> }: <del> mkDerivation  rec { </del> <ins> stdenv.mkDerivation rec { </ins> pname = "qsynth"; <del> version = "0.9.4"; </del> <ins> version = "0.9.13"; </ins> src = fetchurl { url = "mirror://sourceforge/qsynth/${pname}-${version}.tar.gz"; <del> sha256 = "sha256-dlgIkMde7uv4UlMKEPhtZ7MfSTBc7RvHs+Q2yk+G/JM="; </del> <ins> hash = "sha256-SvgZrdS6BwWhNgbovcfhpQKVcu0iwr4dDqeIckuo1fk="; </ins> }; <del> nativeBuildInputs = [ autoconf pkg-config ]; </del> <ins> nativeBuildInputs = [ cmake pkg-config wrapQtAppsHook ]; </ins> buildInputs = [ alsa-lib fluidsynth libjack2 qtbase qttools qtx11extras ]; <del> enableParallelBuilding = true; # Missing install depends: #   lrelease error: Parse error at src/translations/qsynth_ru.ts:1503:33: Premature end of document. #   make: *** [Makefile:107: src/translations/qsynth_ru.qm] Error 1 enableParallelInstalling = false; </del> meta = with lib; { description = "Fluidsynth GUI"; mainProgram = "qsynth";

Discussion:
Package name: qsynth Latest released version: 0.9.13 Current version on the unstable channel: 0.9.4 Current version on the stable/release channel: 0.9.4 Notify maintainers Changelog: Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
ping
Change:
url = "https://nixos.org/releases/nixops/nixops-${version}/nixops-${version}.tar.bz2"; sha256 = "091c0b5bca57d4aa20be20e826ec161efe3aec9c788fbbcf3806a734a517f0f3"; }; <ins> patches = [ # follow redirect in nixos-infect. Remove with the next release. (fetchpatch { url = "https://github.com/NixOS/nixops/commit/fb6d4665e8efd858a215bbaaf079ec3f5ebc49b8.patch"; sha256 = "1hbhykl811zsqlaj3y5m9d8lfsal6ps6n5p16ah6lqy2s18ap9d0"; }) ]; </ins> })

Discussion:
Trying to install nix-ops on macOS I get the following error (I'm using nixpkgs-unstable) Looking at old issues there were a couple on build being broken on darwin. Is it supposed to work? Using verbose, it seems to be an issue related to libvirt indeed looking at the package definition libvirt59_0 is the package broken on darwin. Perhaps it's impossible to upgrade libvirt in python2 ? I'm not an expert on python, so not sure how to move forward with this one. I'm open to testing ideas for a fix. issue open in nixops as well Metadata Please run and paste the result. Maintainer information: