jiebi/CodeConvo huggingface dataset:
Change:
platforms = platforms.unix; mainProgram = "loupe"; }; <del> } </del> <ins> }) </ins>

Discussion:
They apparently fixed the issue where the cursor wouldn’t show up in new tabs. Needs backport to 23.11. Thanks! Package name: vte Latest released version: 0.74.2 Current version on the unstable channel: 0.74.1 Current version on the stable/release channel: 0.74.1 Notify maintainers <!-- 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:
aether-lv2 = callPackage ../applications/audio/aether-lv2 { }; <del> acme-client = callPackage ../tools/networking/acme-client { stdenv = gccStdenv; }; </del> <ins> acme-client = callPackage ../tools/networking/acme-client { stdenv = gccStdenv; libressl = libressl_3_4; }; </ins> adrgen = callPackage ../tools/misc/adrgen { };

Discussion:
LibreSSL 3.4 version will go EOL in October of this year, so we'll need to switch to 3.5
Change:
patches = [ ./darwin.patch <del> # use wl-copy on Wayland - can be dropped with the next version update (fetchpatch { url = "https://github.com/keepassxreboot/keepassxc/commit/6128e5d58294f26411160f44da91087ebe7f4b07.patch"; sha256 = "16q0h7kijqjdbskmk4ar6p3g8vcxr0bq1zrlq2bk16pk10nv4bh1"; }) </del> ]; cmakeFlags = [

Discussion:
Describe the bug program crash when clicking button To Reproduce Steps to reproduce the behavior: a database in keepassxc settings, secret service integration freedesktop integration edit database settings Expected behavior dialog open or something, no crash Screenshots ! Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
This is an . Workaround: Between steps 3 and 4, click "OK" and re-enter settings. You should then be able to edit the database settings.
Change:
++ optional glSupport libGL ; # TODO: maybe liblzo but what would it be for here? <del> configureFlags = (if stdenv.isDarwin then [ </del> <ins> configureFlags = [ "--enable-tee" ] ++ (if stdenv.isDarwin then [ </ins> "--disable-dependency-tracking" "--enable-quartz" "--enable-quartz-font" "--enable-quartz-image" "--enable-ft" <del> ] else ([ "--enable-tee" ] ++ optional xcbSupport "--enable-xcb" </del> <ins> ] else (optional xcbSupport "--enable-xcb" </ins> ++ optional glSupport "--enable-gl" ++ optional pdfSupport "--enable-pdf" )) ++ optional (!x11Support) "--disable-xlib";

Discussion:
pycairo fails on Hydra on darwin: This is serious because it breaks on darwin. This seems to be a result of . cc
We either need to enable the tee frontend in cairo or disable this test. But we explicitly disabled tee for darwin in .
Change:
}; php72base = callPackage generic (_args // { <del> version = "7.2.29"; sha256 = "08xry2fgqgg8s0ym1hh11wkbr36av3zq1bn4krbciw1b7x8gb8ga"; </del> <ins> version = "7.2.31"; sha256 = "0057x1s43f9jidmrl8daka6wpxclxc1b1pm5cjbz616p8nbmb9qv"; </ins> # https://bugs.php.net/bug.php?id=76826 extraPatches = lib.optional stdenv.isDarwin ./php72-darwin-isfinite.patch; }); php73base = callPackage generic (_args // { <del> version = "7.3.16"; sha256 = "0bh499v9dfgh9k51w4rird1slb9rh9whp5h37fb84c98d992s1xq"; </del> <ins> version = "7.3.19"; sha256 = "199l1lr7ima92icic7b1bqlb036md78m305lc3v6zd4zw8qix70d"; </ins> # https://bugs.php.net/bug.php?id=76826 extraPatches = lib.optional stdenv.isDarwin ./php73-darwin-isfinite.patch; }); php74base = callPackage generic (_args // { <del> version = "7.4.6"; sha256 = "0j133pfwa823d4jhx2hkrrzjl4hswvz00b1z58r5c82xd5sr9vd6"; </del> <ins> version = "7.4.7"; sha256 = "0ynq4fz54jpzh9nxvbgn3vrdad2clbac0989ai0yrj2ryc0hs3l0"; </ins> }); defaultPhpExtensions = { all, ... }: with all; ([

Discussion:
, CVSSv3=8.8 (nixos-unstable) CVSSv3=5.4 (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
talks about PHP 7.4.34 which does not exist. The mentioned mb_strtolower bug has been fixed in 7.4.4 and 7.3.16. So this is a false positive. Similar for bogus PHP versions mentioned in the CVE. PHP 7.4.34 does not exist again, and the changelogs don't mention anything similar for 7.3.16.
Change:
os.makedirs(out_path / path) # Copy some files to the minimal repo unchanged <del> for f in ["Compat.toml", "Deps.toml"]: </del> <ins> for f in ["Compat.toml", "Deps.toml", "WeakCompat.toml", "WeakDeps.toml"]: </ins> if (registry_path / path / f).exists(): shutil.copy2(registry_path / path / f, out_path / path)

Discussion:
Steps to reproduce the behavior: -shell -p 'julia.withPackages ["Plots"]' or any other way to build julia.withPackages["Plots"] Also fails for makie and gadfly Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Yes, there are some problems with Julia 1.10 I've been meaning to investigate. In the meantime 1.9 should work:
Change:
binutils-unwrapped = callPackage ../os-specific/darwin/binutils { inherit (darwin) cctools; inherit (pkgs) binutils-unwrapped; <ins> inherit (pkgs.llvmPackages_5) llvm; </ins> }; binutils = pkgs.wrapBintoolsWith {

Discussion:
clang installed through nix doesn't correctly output DWARF data. system: host os: multi-user?: sandbox: version: channels(fghibellini): nixpkgs:
For reference, we use a dummy dsymutil script due to Apple not releasing the original source. This is found here: and . llvm has its own version that should be available to us soon. I'm not sure which version it is first released in.
Thanks for the quick answer! Based on I would think dsymutil is supposed to be Apple specific. Does the llvm release of dsymutil mean this (separate debug info linking) will become standard across operating systems or the llvm dsymutil is also supposed to be used only on OSX?
dsymutil is for MACH-O binaries only. I think OSX is the only place where those are used. You can do something similar on Linux with objcopy though: But this is a good reminder that we need to get the separate debug symbols to work on MacOS as well.
Change:
<del> {lib, stdenv, fetchurl}: </del> <ins> { lib, stdenv, fetchurl, libiconv }: </ins> stdenv.mkDerivation rec { pname = "libiptcdata"; version = "1.0.4"; <ins> buildInputs = lib.optionals stdenv.isDarwin [ libiconv ]; </ins> src = fetchurl { url = "mirror://sourceforge/libiptcdata/${pname}-${version}.tar.gz"; sha256 = "03pfvkmmx762iydq0q207x2028d275pbdysfsgpmrr0ywy63pxkr";

Discussion:
Steps to reproduce the behavior: Adding fixes the issue. <!-- 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:
owner = "systemd"; repo = "systemd-stable"; rev = "v${version}"; <del> hash = "sha256-G43qbNF7znTITSM78sOL0qi8nqaA7qIhmiqP/rZKjXY="; </del> <ins> hash = "sha256-F2wtg12amigd5KNCWmG3b9Yu6PUOby9mQgZ2VFtxl5A=="; </ins> }; # On major changes, or when otherwise required, you *must* reformat the patches,

Discussion:
As said here , you can't download nvidia drivers from ftp, and downloads it from there. Place in your System: NixOS Nix version: Nixpkgs version:
Should be fixed by
Change:
installPhase = '' runHook preInstall <ins> # TODO: Remove when the next stable Itch is stabilized substituteInPlace ./resources/app/package.json  --replace "kitch" "itch" </ins> mkdir -p $out/bin $out/share/${pname}/resources/app cp -r resources/app "$out/share/${pname}/resources/"

Discussion:
Steps to reproduce the behavior: itch system: host os: multi-user?: sandbox: version: channels(root): channels(username): nixpkgs:
Looks like there is an issue already posted for this package NixOS/nixpkgs and there was a PR (NixOS/nixpkgs which uses a canary build instead) posted. Since there is no stable update (the canary builds uses a separate config directory, which is also explained here ) this is still a upstream issue.

I can't update my system when itch should be installed: error: Package ‘electron-11.5.0’ in /nix/store/5wja3wj4lq4gijjgg2lx3966pf6lzijc-nixos- is marked as insecure, refusing to evaluate. Steps to reproduce the behavior: in no error also reproducible on unstable i guess electron needs an update or use a later electron version, if possible system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
It's an upstream issue, trying to use a newer Electron version makes Itch straight up not work (it gets stuck at the initial loading). unfortunately seems to be abandoned. There technically is a new version (25.6.1-canary), but it hasn't been distributed as a binary on , and looking at the commits it doesn't change much. There is really nothing that can be done here. You can do this on your if you don't care about the security risks:
Upstream issue:
Change:
<del> { stdenv, lib, bundlerEnv, ruby_2_2, curl }: </del> <ins> { stdenv, lib, bundlerEnv, ruby }: </ins> bundlerEnv rec { name = "jekyll-${version}"; <del> version = "3.0.1"; ruby = ruby_2_2; gemdir = ./.; </del> <ins> version = (import gemset).jekyll.version; inherit ruby; gemfile = ./Gemfile; lockfile = ./Gemfile.lock; gemset = ./gemset.nix; </ins> meta = with lib; { description = "Simple, blog aware, static site generator";

Discussion:
One uses to create a new tree of files for generating a web site. So the intent is to edit those files. But the files produced are read-only, so user must do a before each new file can be edited. I haven't looked at the source yet, but I imagine this is because jekyll copies the site template out of an installed gem or something, and all the files there are 444 (read-only) because it's in the Nix store. System: NixOS 16.09.1600. (Flounder) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: 16.09.1698.
Have you tried reporting this upstream?
I have not. Will consider that – it seems that a fix would be a one-liner after to do or so. But I'm not able to test easily if that's all that would be needed – the nixpkgs expression is quite behind, carrying jekyll 3.0.1 when current release is 3.4.1. I tried updating too, but ran into bundler problems, and I don't know much about ruby.
You seem to have idea how to fix it. Should really bring this up with upstream. I don't know much about ruby, but nixpkgs manual has a step by step guide: Turned out to be very easy:
So I ran into bundler problems)
Ok, I've pushed a workaround for that
Change:
<ins> { lib, stdenv, fetchFromGitHub, cmake, scdoc, util-linux, xorg, nixosTests, }: stdenv.mkDerivation (finalAttrs: { pname = "ydotool"; version = "1.0.4"; src = fetchFromGitHub { owner = "ReimuNotMoe"; repo = "ydotool"; rev = "v${finalAttrs.version}"; hash = "sha256-MtanR+cxz6FsbNBngqLE+ITKPZFHmWGsD1mBDk0OVng="; }; postPatch = '' substituteInPlace Daemon/ydotoold.c  --replace "/usr/bin/xinput" "${xorg.xinput}/bin/xinput" substituteInPlace Daemon/ydotool.service.in  --replace "/usr/bin/kill" "${util-linux}/bin/kill" ''; strictDeps = true; nativeBuildInputs = [ cmake scdoc ]; passthru.tests.basic = nixosTests.ydotool; meta = { description = "Generic Linux command-line automation tool"; homepage = "https://github.com/ReimuNotMoe/ydotool"; license = lib.licenses.agpl3Plus; mainProgram = "ydotool"; maintainers = with lib.maintainers; [ willibutz kraem ]; platforms = lib.platforms.linux; }; }) </ins>

Discussion:
requires to be running in order to be used otherwise it aborts and crashes (see ). It would make sense to have a NixOS configuration option in order to automatically configure to run. Some NixOS module option (perhaps ) that automatically configures and runs as a systemd service in the background.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
preCheck = "export CI=true"; }) super.aeson-typescript; <del> # Enable extra optimisations which increase build time, but also # later compiler performance, so we should do this for user's benefit. # Flag added in Agda 2.6.2 Agda = appendConfigureFlag "-foptimise-heavily" super.Agda; </del> <ins> Agda = lib.pipe super.Agda [ # Enable extra optimisations which increase build time, but also # later compiler performance, so we should do this for user's benefit. # Flag added in Agda 2.6.2 (enableCabalFlag "optimise-heavily") # Enable debug printing, which worsens performance slightly but is # very useful. # Flag added in Agda 2.6.4.1, was always enabled before (enableCabalFlag "debug") ]; </ins> # ats-format uses cli-setup in Setup.hs which is quite happy to write # to arbitrary files in $HOME. This doesn't either not achieve anything

Discussion:
Agda 2.6.4.1 a configure flag that controls whether debug printing (with ) is enabled (previously it was always enabled). Should we enable this? I am leaning strongly towards "yes" as I use debug printing quite often and it would suck to have to rebuild Agda. cc
is there any downside to enabling it?
Performance is , though I'd say not in a way that matters.
If it was true by default before, we should keep that default. We can add an option to the derivation to make it configurable.
Opened I am not sure how to add an option to the derivation (I think should do) and I don't have enough motivation to add an option to the wrapper.
Change:
packagesWithBuildInputs = { # sort -t '=' -k 2 <ins> deldir = lib.optionals stdenv.isDarwin [ pkgs.libiconv ]; </ins> gam = lib.optionals stdenv.isDarwin [ pkgs.libiconv ]; <ins> interp = lib.optionals stdenv.isDarwin [ pkgs.libiconv ]; </ins> RcppArmadillo = lib.optionals stdenv.isDarwin [ pkgs.libiconv ]; quantreg = lib.optionals stdenv.isDarwin [ pkgs.libiconv ]; rmutil = lib.optionals stdenv.isDarwin [ pkgs.libiconv ];

Discussion:
deldir (). Tail (): I am actually trying to install , of which appears to be a transitive dependency. (best guess per )
Also reproduce with x86_64-darwin can you update your title
Darwin requires as an additional dependency for many packages, but we don't have hydra building the tree on darwin to find them. I also don't have a mac so it's hard for me to work on darwin support. Maybe we could propagate in the expression on darwin systems. Any thoughts
Can you give command to build all R packages so I can see the list of packages that require it maybe the set is small.
Easiest way is probably run the hydra jobset defined at with set. If you don't have/want a hydra server then you can get a list of derivations to build by using the evaluator out of the package: This will dump JSON to stdout containing details about each of the packages, including the derivation path. If you pull out the derivation paths (e.g., with ) you can then build them with .
Closest package name I found is and it failed:
is in the package.
It is unsupported on Darwin.
Not sure it is useful data, but I've attached the output of the suggested command (with ) ran on a machine. Obviously this won't give you the derivations, but maybe the package names are enough?
It require the deriver file I will find a solution, will try to generate a command from name inside . Still it doesn't block the associated PR.
The first key in the json file I attached is , and I can build it by executing in the root nixpkgs dir. Hopefully a similar procedure works for all relevant packages without having the files.
Oh I haven't though to that way. a simpler invocation can be done with or with flakes
I removed since it is not a packages. with the numbers of packages and my disk space I think it won't fit in my disk. Can ofBorg build all those ? if no I will try to do by batch.
Change:
maintainers = []; platforms = lib.platforms.unix; <ins> knownVulnerabilities = [ "CVE-2021-42785" ]; # Unfortunately, upstream doesn't maintain the 1.3 branch anymore, and the # new 2.x branch is substantially different (requiring either Windows or Java) </ins> }; }

Discussion:
, CVSSv3=9.8 (nixos-21.05, nixos-21.11, nixos-unstable) Buffer Overflow vulnerability in of TightVNC Viewer allows a remote attacker to execute arbitrary instructions via a crafted FramebufferUpdate packet from a VNC server. Scanned versions: nixos-21.05: ; nixos-21.11: ; nixos-unstable: .
I'm thinking we're going to have to just mark this as vulnerable - upstream don't maintain the open source 1.3 branch anymore, instead there's a windows-only proprietary 2.x version.
I agree, and just opened a pull request implementing your suggestion.
alternatives to tightvnc - html teamviewer - heavy, commercial (closed source?) tigervnc looks like a worthy replacement, and we should remove tightvnc from nixpkgs
Change:
patchShebangs . <del> ./bootstrap --no-git --gnulib-srcdir=${gnulib} </del> substituteInPlace ./configure --replace '/usr/share/fonts/unifont' '${unifont}/share/fonts' '';

Discussion:
After upgrading to 21.05, when running , I get the following warning: Everything else seems to work fine, but it's unclear what has gone wrong here, or if I should be worried. Metadata Maintainer information:
discussed here a bit you can safely ignore it to hide it we could add to the or to
Not sure if my case is related, but I had the same error after : The overall install didn't error. Attempting to reboot, it would be unable to boot:
My boot got fixed after converting my MBR to GPT and creating an ESP partition and setting it to use systemd-boot instead of GRUB. If GRUB continues to work with people that see this warning, it's unlikely that my boot problems are related. (But, still, a different bug; if MBR got deprecated, there should have been an announcement.)
But the issue is quite severe (I just lost hours on it because it happened on a remote server which boots very slowly on a web-mounted rescue iso), and I could only get my system running again by reverting to . I'd propose to throw out the new version () for now. I can't do GPT, because the system only has a legacy BIOS (no UEFI), it appears that this is the reason this issue has flown under the radar? Same error referenced , it appears to be an issue with the grub package itself. EDIT: since OP defined a "parallel" but much less severe bug, I made a new report here:
Change:
installPhase = '' mkdir -p $out/bin cp -r bin/Release/OmniSharp.Stdio.Driver/net6.0 $out/src <ins> # Delete files to mimick hacks in https://github.com/OmniSharp/omnisharp-roslyn/blob/bdc14ca/build.cake#L594 rm $out/src/NuGet.*.dll rm $out/src/System.Configuration.ConfigurationManager.dll </ins> makeWrapper $out/src/OmniSharp $out/bin/omnisharp  --prefix DOTNET_ROOT : ${dotnet-sdk}  --suffix PATH : ${dotnet-sdk}/bin

Discussion:
complains that it can't find. Install & try to start it. should work without throwing an error, at least when is set.
I found the cause for this issue on my machine. I was using . When I change it to use use only one SDK, omnisharp will work again: This works for my use-case since I only have one SDK installed at the moment. It's not optimal, though and it was working previously at some point.
Also, if I , omnisharp is still working. So I guess it should be possible to fix this in:
I get another error now, though: Possibly related:
I got the same error. Is it caused by a version incompatibility? The latest version of the package in nixpkgs-unstable is 1.38.1, and the latest version of is . v1.38.2 of - - mentions updating build tools to match dotnet 6.0.201. Does updating omnisharp or downgrading dotnet help this issue?
Omnisharp has been updated to v1.38.2 (on master, at least), does this error still occur?
Still occurs for me. Now the error is that it cannot find System.Configuration.ConfigurationManager with version 4.0.3 It seems there is a mismatch, dotnet-sdk package contains System.Configuration.ConfigurationManager with version 4.0.0: The same error was reported in omnisharp repository -
I've been seeing that same error thrown on my end as well. Went ahead and bumped the dotnet core packages, and that doesn't seem to change the result (tested sdk 6.0.202): Interestingly, sdk 7.0.100-preview.3..4 also showed 4.0.0.0: (Will be PRing the updates, and addition of 7.0, momentarily) EDIT: Won't be PRing the updates yet, breaks a number of packages currently. Will PR the addition of 7.0 though
Possibly related: OmniSharp/omnisharp-roslyn
Seems like the omnisharp-roslyn package incorretly refernces this dll. It seems like a problem with the upstream repo, not the nix packaging.

Btw, I made a PR with the dotnet 6 bump here:
Still getting this error, anyone has a solution for it? UPDATE: Downgrading this single package to stable temporarily fixed it.
After some investigation, the issue with System.Config.ConfigurationManager in upstream repo was fixed by This was fixed by removing the problematic dll during build, causing omnisharp-roslyn to find the dll in dotnet sdk folder, and bind properly. But since it was to the file, which nix build doesn't use, the fix did not carry over to nixpkgs. The simple solution is to add a manual removal of dlls to the , mimicking the hack upstream. This causes omnisharp to work again on my machine: I'm going to try adding the above fix in a PR to nixpkgs.
Change:
license = stdenv.lib.licenses.bsd3; platforms = stdenv.lib.platforms.unix; maintainers = with stdenv.lib.maintainers; [ fuuzetsu ]; <ins> broken = true; </ins> }; })

Discussion:
As of Agda 2.5.1 (which comes on the latest nixos-unstable release), both nixpkgs' agda-stdlib (from git nominally at version 2.4.2.3) and an updated version (v0.12, the most recent release) fail to build. Some modules are checked successfully, but it gets stuck at (the first builtin module it finds). For this module only, it tries to write to . Output: System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: ""
has the same issue, meaning that there has probably been some change in Agda. The problem seems to be that writes a file for each file it checks, and some files it's checking are in the Nix store (specifically, in ). I think it's to do with . Maybe it would work if these were checked when building .
Current status: .
Fixed by .
Let's keep this open until the fix lands in master.
Change:
mdl = callPackage ../development/tools/misc/mdl { }; <ins> meraki-cli = python3Packages.callPackage ../tools/admin/meraki-cli { }; </ins> python-matter-server = with python3Packages; toPythonApplication python-matter-server; minify = callPackage ../development/web/minify { };

Discussion:
Project description A simple CLI tool to automate and control your Cisco Meraki Dashboard Metadata homepage URL: source URL: license: mit platforms: unix
Change:
inherit pkgs config; lib = pkgs.lib; format = "qcow2"; <del> contents = [{ source = pkgs.writeText "testFile" "contents"; target = "/testFile"; user = "1234"; group = "5678"; mode = "755"; }]; </del> <ins> contents = [ { source = pkgs.writeText "testFile" "contents"; target = "/testFile"; user = "1234"; group = "5678"; mode = "755"; } { source = ./.; target = "/testDir"; } ]; </ins> }) + "/nixos.qcow2"; in makeEc2Test {

Discussion:
takes an argument that copies source paths into the resulting VM image. It seems to work fine when the sources are files or , but when copying directories, they end up nested inside the target directory named with a nix-store-like path. This is not what I expected, it is hard to use, and I do not think it is the intended behavior. these files: (and additional , see attached ). the VM image with . the VM image, e.g. with . in with credentials literal . that contains a subdirectory with a Nix-store-like path, e.g. instead of . I expected that the source would end up at the target, as happens with contents objects that are files. ! I will have a PR with a test and fix up soon. When changing the behavior of a function that is already widely used, even fixing a bug can cause problems for people. I checked, but I did not find any existing usages of with directories in . And given how broken the directory support seems, I suspect that it is not actually used in the wild, so I think it is okay to fix this behavior. Please run and paste the result.