jiebi/CodeConvo huggingface dataset:
Change:
url = "https://github.com/GStreamer/gst-python/commit/f98c206bdf01529f8ea395a719b10baf2bdf717f.patch"; sha256 = "04n4zrnfivgr7iaqw4sjlbd882s8halc2bbbhfxqf0sg2lqwmrxg"; }) <ins> ] ++ [ # Fix linking against Python 3.8 # https://gitlab.freedesktop.org/gstreamer/gst-python/merge_requests/30 (fetchpatch { url = "https://gitlab.freedesktop.org/gstreamer/gst-python/commit/22f28155d86e27c4134de4ed2861264003fcfd23.patch"; sha256 = "Y70qVguHUBmmRVMFBKAP0d6anBQw5W0TKyu2bAwxbQg="; }) </ins> ]; mesonFlags = [

Discussion:
The failure is limited to Python 3.8. Update in does not help.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Possibly, we need to cherry-pick
Change:
src = fetchurl { url = "mirror://kernel/linux/kernel/v5.x/linux-${kversion}.tar.xz"; <del> sha256 = "1xxjbxldrhmnh2q6rykpxyfbj8xqgl82q30n8sfavrzr14bb4jcp"; </del> <ins> sha256 = "1yicgvq413801qrfzr0rdzwgg45dszrvfd6y9dmrhak9bk36lvck"; </ins> }; kernelPatches = let rt-patch = { name = "rt"; patch = fetchurl { url = "mirror://kernel/linux/kernel/projects/rt/${branch}/older/patch-${version}.patch.xz"; <del> sha256 = "11zk02ni3b0l1wwrfvyc1q92bd9as61hwgbwlj42xv5gbpd39jlw"; </del> <ins> sha256 = "0qlk43g5c0apspdg56ccb4259903nvadv4pnga07i4lg6xwb5xjw"; </ins> }; }; in [ rt-patch ] ++ kernelPatches;

Discussion:
Apparently upstream stable kernels 6.1.65 (NixOS 23.11 default) and .64 have a cherry-picking bug that can create data corruption on ext4 Probably NixOS should update to 6.1.66 (released 2 days ago) as soon as possible
Looks like this was already dealth with: Currently building on Hydra:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I believe the realtime kernel from the branch still contains this bug? Made an issue:
Change:
nvme-cli = callPackage ../os-specific/linux/nvme-cli { }; open-vm-tools = callPackage ../applications/virtualization/open-vm-tools { <del> inherit (gnome2) gtk gtkmm; </del> <ins> inherit (gnome3) gtk gtkmm; </ins> }; open-vm-tools-headless = open-vm-tools.override { withX = false; };

Discussion:
The service fails to start, giving the following error messages in : Install a fresh copy of NixOS 18.03 in a VM under VMware Fusion 10.1.3 on macOS 10.12.x. Configure relevant parts in , e.g.: Based on the code in it seems that the contents of the file , which is scanned by , is simply too large: I tested that by creating a file (which is also scanned by ), with only part of the contents: After a few seconds, when the service tries to start again, there's only one of the previously three error messages in: The service started, the above error message is for the still remaining and too large file (to verify, let the contents of be identical to that of and notice that the other error messages comes back in the log file).
Ping, looks like you're the maintainer :) I have a test VM set up for this so I can help debug it.
FWIW, I also verified that it doesn't make a difference if the file is a regular file or a symlink, same symptoms apply. I also verified that removing the last three lines from to make it smaller works, just the same way it works with the substitute file .
My /var/log/vmware- file is littered with the same errors as yours, but the vmware service is still running. I'll note I don't have any shared folders.
Can you also report this upstream? The file does not look that big too me:
I guess I can do that, raising the question "shouldn't it be allowed to be bigger?". Regardless of what it looks like, it is evidently too big for the vmware-vmsvc code to handle as it is now :/ I'm thinking of patching the vmware service in the Nix derivation, but it would of course be better to have it done upstream or that Nix generated a smaller file.
I also ran the lsb release tool on NixOS in the VM and didn't get any output. Is that the expected result? I'm guessing not... If the lsb release tool worked on NixOS that might also solve the problem. Can you let me know if running lsb_release has any output for you?
lsb-release just ignore this file:
Can you elaborate on how the tool could solve the problem? AFAICT it just produces output.

I assume you mean that if we take this output and put it in an file, the problem is solved? But the file in question would still be restricted to the same size limitations as the other files that are scanned, or is there a difference in limitation between this one and other files? FWIW, same here, not much info from :
I didn't review the openvm-tools closely enough to say but after a quick glance it appears that the source file you linked can use the output of lsbrelease to identify the distro. I wondered if adding a quick substitution in the source code to ${}/bin/lsbrelease for /usr/bin/lsb_release might be enough to identify the distro.
Reported upstream, let's hope they increase the buffer, so we don't have to require additional binaries just to make this service work.
Started working on a PR for this in .
Change:
unstable = fetchurl rec { # NOTE: Don't forget to change the hash for staging as well. <del> version = "9.5"; </del> <ins> version = "9.6"; </ins> url = "https://dl.winehq.org/wine/source/9.x/wine-${version}.tar.xz"; <del> hash = "sha256-Es8vtwmBNOI1HEnqO6j02ipnTx+HIr69TDpKbKbS6XU="; </del> <ins> hash = "sha256-Dglg7YK2AX6ILtozOLrRJwoRd7bPBfA6wfqxVavoIEg="; </ins> inherit (stable) patches; ## see http://wiki.winehq.org/Gecko

Discussion:
Package name: wine Latest released version: 9.6 <!-- Search your package here: --- Current version on the unstable channel: 9.5 Current version on the stable/release channel: 8.20 <!-- 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 <!-- 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:
, fetchurl , appimageTools , makeWrapper <del> , electron </del> <ins> # graphs will not sync without matching upstream's major electron version , electron_24 </ins> , git , nix-update-script }:

Discussion:
Search seems to work for page titles but not page text. Steps to reproduce the behavior: +K, look for text that's in a page Returns results for pages that have the given text.
The Issue appears to be related to NODE and Electron versions. If you run Logseq and trigger a re-index of the graph, you will get the following error Logseq upstream currently uses Electron , if you override the electron version for Logseq to , it will work, however is marked as EOL in nixpkgs, so you will also need to add an exception for the insecure package. I tried using all of the non-EOL electron versions (22-24) and they all throw the NODE version error for bettersqlite3 during re-indexing. So for a current workaround you can apply this overlay and allow the broken electron package. as well as including the fix from You must re-index to get full text search back once you have Logseq with the above override running.
Change:
rustPlatform.buildRustPackage rec { pname = "nix-du"; <del> version = "1.2.0"; </del> <ins> version = "1.2.1"; </ins> src = fetchFromGitHub { owner = "symphorien"; repo = "nix-du"; rev = "v${version}"; <del> sha256 = "sha256-HfmMZVlsdg9hTWGUihl6OlQAp/n1XRvPLfAKJ8as8Ew="; </del> <ins> sha256 = "sha256-WImnfkBU17SFQG1DzVUdsNq3hkiISNjAVZr2xGbgwHg="; </ins> }; <del> cargoHash = "sha256-oUxxuBqec4aI2h8BAn1WSA44UU7f5APkv0DIwuSun0M="; </del> <ins> cargoHash = "sha256-gE99nCJIi6fsuxzJuU80VWXIZqVbqwBhKM2aRlhmYco="; </ins> doCheck = true; nativeCheckInputs = [ nix graphviz ];

Discussion:
Steps to reproduce the behavior: nix-du on unstable Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Upstream issue - Commit that should have fixed it: New tag with it - (from yesterday):
fixed in
Change:
}; command-t = super.command-t.overrideAttrs (old: { <del> buildInputs = [ ruby ]; </del> <ins> nativeBuildInputs = [ getconf ruby ]; </ins> buildPhase = '' substituteInPlace lua/wincent/commandt/lib/Makefile  <del> --replace '/bin/bash' 'bash' </del> <ins> --replace '/bin/bash' 'bash'  --replace xcrun "" </ins> make build rm ruby/command-t/ext/command-t/*.o '';

Discussion:
The vim plugin is currently undergoing a full rewrite. As part of this, it appears to have changed how it compiles. On Darwin it now compiles using (). is not available when building in Nix and so it fails. Most likely the reference to can just be patched out. It also runs () which is also reporting a "command not found" line, although this appears to be non-fatal. This affects all platforms. Steps to reproduce the behavior: I don't know if anyone in particular is responsible here but appears to have fixed the build of this plugin most recently Please run and paste the result.
Change:
mkdir -m 1777 -p /var/tmp <del> # Empty, read-only home directory of many system accounts. mkdir -m 0555 -p /var/empty </del> <ins> # Empty, immutable home directory of many system accounts. mkdir -p /var/empty # Make sure it's really empty ${pkgs.e2fsprogs}/bin/chattr -i /var/empty find /var/empty -mindepth 1 -delete chmod 0555 /var/empty ${pkgs.e2fsprogs}/bin/chattr +i /var/empty </ins> ''; system.activationScripts.usrbinenv = if config.environment.usrbinenv != null

Discussion:
Title sums it up pretty well. The default value of home is "/var/empty" and createHome modifies that to have the usual home directory permissions for that user, which breaks polkitd (among other things). It's easy to assume that createHome will default to creating a conventional /home/<name?directory, so the documentation should be updated and/or the default behavior changed. The polkitd breakage manifests with the following error when e.g. systemctl commands requiring authentication are ran:
Change:
[ <del> { "cryptpad": "git+https://github.com/xwiki-labs/cryptpad.git#4.9.0" } </del> <ins> { "cryptpad": "git+https://github.com/xwiki-labs/cryptpad.git#4.11.0" } </ins> ]

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- 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! --- name: cryptpad <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 4.9.0 desired version: 4.11.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
cdrtools, curl, gawk, <ins> glxinfo, </ins> gnugrep, gnused, jq,

Discussion:
Package name: quickemu Latest released version: 4.9.5 <!-- Search your package here: --- Current version on the unstable channel: 4.9.4 Current version on the stable/release channel: 4.9.5 <!-- 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 <!-- If the result shows no maintainers, tag the person that last updated the package. --fedx- 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:
<del> { lib, stdenv, fetchurl, zlib }: </del> <ins> { lib, stdenv, fetchurl, fetchpatch, autoreconfHook, giflib, libjpeg, libpng, libX11, zlib , static ? stdenv.hostPlatform.isStatic , withX ? !stdenv.isDarwin }: </ins> stdenv.mkDerivation { pname = "libAfterImage";

Discussion:
Describe the bug I'm trying to use latest unstable branch in a flake that contains ROOT 6.22.08. The package contains a program . When I try to launch that, I got the following segmentation fault, hinting on build time and runtime conflict for : To Reproduce Steps to reproduce the behavior: from Expected behavior The program should run w/o problem Additional context The command line runs OK, provided that no graphical interface is invoked. Same segmentation fault would occur if in a shell, I do the following: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Not sure if this is useful, as I tried to install as part of my flake yet I still get this: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Can you reproduce the crash with ?
Yes:
I don't have an access to NixOS at the moment to reproduce. Do you think you could git-bisect this?
Yes. I'll try to do this sometime this week, if I have time. Just to be sure, everything is OK on macOS?
Yes, it works great:
I did a poorman's bisect with : I think the commit that breaks ROOT is . The commit immediately before that still has a working ROOT (6.18).
On a side, I first tried with the following: But complains: Do you have any suggestion to make this automated bisect work?
git-bisect expects certain return codes to be returned. Perhaps you could try wrapping it in
That is helpful. Google says this is an old problem [1], so it has probably to do with incomplete afterimage unvendoring. [1] https://root-
In the end, the problem was this one: https://root-
Wow, this is a very old "problem" then. I guess previously was not used as a build input so that we never noticed this.
Change:
### R ### radare2-cutter = cutter; # Added 2021-03-30 <ins> railcar = throw "'railcar' has been removed, as the upstream project has been abandoned"; # Added 2022-06-27 </ins> raspberrypi-tools = throw "raspberrypi-tools has been removed in favor of identical 'libraspberrypi'"; # Added 2020-12-24 rawdog = throw "rawdog has been removed from nixpkgs as it still requires python2"; # Added 2022-01-01 rdiff_backup = throw "'rdiff_backup' has been renamed to/replaced by 'rdiff-backup'"; # Converted to throw 2022-02-22

Discussion:
I was curious about railcar and noted that it's marked as so I decided to give it a try. The first attempt failed at an error over a missing in libseccomp: I gather this is Linux-only and could find at least one other PR that fixed a macOS build of a different project by just removing it as a buildInput () and the cargo build fell over on some issues with caps: Other notes: I looked to see if Hydra was building this for darwin and don't see any builds. I guess hydra is smart enough not to bother with darwin given the libseccomp input. I noticed that ofborg didn't bother with building darwin on the original PR, either. Also, I noticed that oracle has archived the railcar repo. I only see at the moment. They've done some work on the CI earlier this year, at least, which seems to be a good signal? Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(abathur): nixpkgs:
I marked this as stale due to inactivity. &rarr;
Change:
acl_file ${aclFile} persistence true allow_anonymous ${boolToString cfg.allowAnonymous} <del> bind_address ${cfg.host} port ${toString cfg.port} </del> <ins> listener ${toString cfg.port} ${cfg.host} </ins> ${passwordConf} ${listenerConf} ${cfg.extraConf}

Discussion:
Describe the bug Expected behavior The nixos module should be aware of the deprecated options and the resulting config should be updated. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
Change:
dontConfigure = true; enableParallelBuilding = true; <ins> env = { # silence service.h error NIX_CFLAGS_COMPILE = "-Wno-implicit-function-declaration"; }; </ins> postPatch = '' # aarch64 code is compiled on all targets, which causes our Apple SDK headers to error out. # Since multilib doesnt work on darwin i dont know of a better way of handling this.

Discussion:
I don’t know what has changed in "${}clang" that caused this problem Steps to reproduce the behavior: yabai work well <!-- 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.
Thanks for the report, have a PR out to resolve this in the package.
Change:
pname = "ibus-hangul"; version = "1.5.5"; <del> src = fetchurl { url = "https://github.com/libhangul/ibus-hangul/releases/download/${version}/${pname}-${version}.tar.xz"; sha256 = "sha256-parIgobNGJYCKYYOPhp3iXinrqpIStms+kgoS4f9w7s="; </del> <ins> src = fetchFromGitHub { owner = "libhangul"; repo = "ibus-hangul"; rev = version; hash = "sha256-x2oOW8eiEuwmdCGUo+r/KcsitfGccSyianwIEaOBS3M="; </ins> }; patches = [

Discussion:
Build on master Steps to reproduce the behavior: Full log: it builds successfully with python39 <!-- 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]:
It builds successfully with python39
Change:
"-e" (builtins.toFile "bash-builder.sh" '' export CONFIG_SHELL=$SHELL <ins> # Normalize the NIX_BUILD_CORES variable. The value might be 0, which # means that we're supposed to try and auto-detect the number of # available CPU cores at run-time. NIX_BUILD_CORES="''${NIX_BUILD_CORES:-1}" if ((NIX_BUILD_CORES <= 0)); then guess=$(nproc 2>/dev/null || true) ((NIX_BUILD_CORES = guess <= 0 ? 1 : guess)) fi export NIX_BUILD_CORES </ins> bash -eux $buildCommandPath '') ];

Discussion:
When built with default Nix options, is 0, meaning auto. The stdenv guesses the "correct" core count: minimal-bootstrap just makes fail. Here the build of for example: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Change:
# LLVM toolchain patches. patch -p1 -d llvm-project/clang -i ${./patches/0005-clang-toolchain-dir.patch} patch -p1 -d llvm-project/clang -i ${./patches/0006-clang-purity.patch} <ins> patch -p1 -d llvm-project/compiler-rt -i ${../llvm/common/compiler-rt/libsanitizer-no-cyclades-11.patch} </ins> substituteInPlace llvm-project/clang/lib/Driver/ToolChains/Linux.cpp  --replace 'SysRoot + "/lib' '"${glibc}/lib" "'  --replace 'SysRoot + "/usr/lib' '"${glibc}/lib" "' 

Discussion:
When trying to build the swift package, it inevitably fails at the same point in two of my machines. In particular, it seems to fail at the following point (): Steps to reproduce the behavior: the following a long time for it to ultimately fail with the above message. I expect the swift package to successfully build. I have not tried to build it using any other method than the way outlined in <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
It looks like swift is using a bundled llvm source tree, so we will have to apply the patch from
Out of curiosity do you know if there is a version of nixpkgs that contains a Swift package I could possibly build? Or is it somehow dependant on how my system is configured?
Certainly, that patch was only needed since bumping our userspace linux headers from 5.12 to 5.14, so I would expect any commit before that would work. According to Hydra, () was the most recent success.
Change:
++ (concatLists (mapAttrsToList (_k: _v: [ "--client-option" "${_k}=${_v}" ]) cfg.clientOptions)) ++ [ "--terminal-type" cfg.terminalType ] ++ optionals cfg.checkOrigin [ "--check-origin" ] <ins> ++ optionals cfg.writeable [ "--writable" ] # the typo is correct </ins> ++ [ "--max-clients" (toString cfg.maxClients) ] ++ optionals (cfg.indexFile != null) [ "--index" cfg.indexFile ] ++ optionals cfg.enableIPv6 [ "--ipv6" ]

Discussion:
After a recent upgrade ( followed by ) the browser-based terminal in my setup, served with ttyd, no longer accepts user input (i.e. where the user can type and enter commands through the browser). Normally you are greeted with a terminal login screen and can enter username/password and log in, but it is now no longer possible to type or submit either. After researching, there is a breaking change in ttyd version =1.7.4, where the terminal is now readonly by default, users must pass or to get an interactive terminal. Note that the release notes appear to incorrectly indicate a lower-case flag, upper-case is needed. Consulting both the listed and the nixpkgs , there is no currently no way to pass this option. I am unsure who if anyone is the maintainer of this service, although I see that maintains the ttyd package. I will attempt to fix and submit a PR.
Change:
checkInputs =  [ pytest glibcLocales ]; <ins> # Necessary for the tests to pass on Darwin with sandbox enabled. # Black starts a local server and needs to bind a local address. __darwinAllowLocalNetworking = true; </ins> # Don't know why these tests fails checkPhase = '' LC_ALL="en_US.UTF-8" pytest 

Discussion:
tests fails on Darwin in sandbox mode: system: host os: multi-user?: sandbox: version: channels(smaret): nixpkgs:
CC
Oddly, the tests run fine on Hydra:
I doubt this has anything to do with black but rather with networking on mac OS in the sandbox. This sounds related:
I think you're right. Thanks for pointing the sandbox issue.
Change:
] ++ lib.optionals (!config.system.etc.overlay.mutable) [ "ro" ]); <del> wantedBy = [ "initrd-fs.target" ]; </del> <ins> requiredBy = [ "initrd-fs.target" ]; </ins> before = [ "initrd-fs.target" ]; requires = lib.mkIf config.system.etc.overlay.mutable [ "rw-etc.service" ]; after = lib.mkIf config.system.etc.overlay.mutable [ "rw-etc.service" ];

Discussion:
I set and rebooted, all went fine. When rebuilding and switching though, I get this error and I still have the old etc: <!-- 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:
resolvconfOptions = cfg.extraOptions ++ optional cfg.dnsSingleRequest "single-request" <del> ++ optional cfg.dnsExtensionMechanism "edns0"; </del> <ins> ++ optional cfg.dnsExtensionMechanism "edns0" ++ optional cfg.useLocalResolver "trust-ad"; </ins> configText = ''

Discussion:
When using unbound, the option in Can this be to the unbound module, so that this option is set by default if unbound is set to enabled? Or is this a bad idea? Maybe this is more relevant now after the support for unbound has been by NetworkManager. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
uhm not sure, I'm not the unbound maintainer. I think you want to talk to: (btw would you mind adding yourself as module maintainer you did most of the recent work on it from skimming through the commit log)
I don't think should be something by module. Perhaps it should be set when is set to true in the module?
cc :seenoevil:
o no. Unfortunate timing.