jiebi/CodeConvo huggingface dataset:
Change:
sha256 = "1fsn6aa9a68cfbna9s00l1ry4ym1fr7ii2f45hzj2fipxfpqihwy"; }; <del> postPatch = '' chmod +x meson_post_install.py # patchShebangs requires executable file patchShebangs meson_post_install.py ''; </del> <ins> # Uncomment when switching back to meson # postPatch = '' #   chmod +x meson_post_install.py # patchShebangs requires executable file #   patchShebangs meson_post_install.py # ''; </ins> nativeBuildInputs = [ <del> meson ninja </del> <ins> autoreconfHook # Remove when switching to meson # meson ninja </ins> pkgconfig gettext makeWrapper libxml2 libxslt docbook_xsl docbook_xml_dtd_42 ];

Discussion:
Upstream bug: Random hydra log: We should probably switch back to autotools as suggested until it's fixed upstream? Or would turning parallel building off fix it too? cc
Sounds good to me.
Change:
kramdown-asciidoc = callPackage ../tools/typesetting/kramdown-asciidoc { }; lychee = callPackage ../tools/networking/lychee { <del> inherit (darwin.apple_sdk.frameworks) Security; </del> <ins> inherit (darwin.apple_sdk.frameworks) Security SystemConfiguration; </ins> }; magic-vlsi = callPackage ../applications/science/electronics/magic-vlsi { };

Discussion:
Package name: Latest released version: 0.14.2 <!-- Search your package here: --- Current version on the unstable channel: 0.13.0 Current version on the stable/release channel: 0.13.0 <!-- 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:
python3Packages.buildPythonApplication rec { pname = "i3a"; <del> version = "2.0.1"; </del> <ins> version = "2.1.1"; </ins> src = fetchPypi { inherit pname version; <del> hash = "sha256-2k1HYtgJ76qXLvX6RmOSKtMMg+K722n8U9YmBANvQvE="; </del> <ins> hash = "sha256-b1bB7Gto4aL1rbQXIelBVhutjIvZY+K+Y66BGN7OcCs="; </ins> }; <del> postPatch = '' substituteInPlace setup.py  --replace "python_requires='>=3.7,<3.10'," "python_requires='>=3.7'," ''; </del> nativeBuildInputs = [ python3Packages.setuptools-scm ]; propagatedBuildInputs = [ python3Packages.i3ipc ];

Discussion:
Hello, I'm the author of i3a. Thanks for packaging it for nix. I noticed that nix package contains outdated metadata. It would be great for nix users if you could update it. Current homepage for i3a is and source code link is The latest version is 2.1.1: Thanks, mg
Change:
qtbase = qt4; }; <del> scfbuild = python2.pkgs.callPackage ../tools/misc/scfbuild { }; </del> <ins> scfbuild = python3.pkgs.callPackage ../tools/misc/scfbuild { }; </ins> scriptaculous = callPackage ../development/libraries/scriptaculous { };

Discussion:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency.

The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.
Change:
nccl = final.callPackage ../development/libraries/science/math/nccl { }; <ins> nccl-tests = final.callPackage ../development/libraries/science/math/nccl/tests.nix { }; </ins> autoAddOpenGLRunpathHook = final.callPackage ( { makeSetupHook, addOpenGLRunpath }: makeSetupHook { name = "auto-add-opengl-runpath-hook";

Discussion:
Project description tests the correctness and performance of NVIDIA's NCCL library: Given the upcoming work surrounding NCCL (and CUDA redistributable as a whole), it's important that we have utilities to ensure that changes don't introduce breakages. Metadata homepage URL: URL: bsd3 platforms: linux
Change:
owner = pname; repo = pname; rev = "refs/tags/v${version}"; <del> hash = "sha256-Q4NHUHay1/xb+V494n96jxE1VyAP7uVyQbIbS0/E85c="; </del> <ins> hash = "sha256-XXs9KjiAPzZ932r4UJ87RpM+qhg/bNDWEYsq2Ua6SRw="; </ins> }; patches = [

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags:
This was caused by your commit . Could you please revert or push a fix?
I kindly ask you to help the python-updates runs which make the python package set maintainable by fixing this build failure by updating the ignored test list and considering to support python-updates runs in the future and proactively updating the packages you maintain. Thank you.
As evidenced by this issue, python-updates is breaking packages... the opposite of increasing maintainability! It is incumbent on commit authors to test their changes before merging and produce fixes/rollbacks when their changes result in breakages.
Having a severely outdated package set is also increasing the burden on everyone and maintaining packages harder which outweighs the occasional breakage. This is not always possible, otherwise merging any update to a package that has more than a few hundred reverse deps becomes impossible and we are basically halting nixpkgs to a grind.
Change:
<ins> { lib , buildPythonPackage , fetchFromGitHub , installShellFiles , pygments , unittestCheckHook }: buildPythonPackage rec { pname = "jello"; version = "1.6.0"; format = "setuptools"; src = fetchFromGitHub { owner = "kellyjonbrazil"; repo = "jello"; rev = "v${version}"; hash = "sha256-EN09Kcnw4HNT2roCoQyZkoHEfkM9qxqtneZPuBg46z4="; }; nativeBuildInputs = [ installShellFiles ]; propagatedBuildInputs = [ pygments ]; nativeCheckInputs = [ unittestCheckHook ]; pythonImportsCheck = [ "jello" ]; postInstall = '' installManPage man/jello.1 ''; meta = with lib; { description = "CLI tool to filter JSON and JSON Lines data with Python syntax"; homepage = "https://github.com/kellyjonbrazil/jello"; changelog = "https://github.com/kellyjonbrazil/jello/blob/${src.rev}/CHANGELOG"; license = licenses.mit; maintainers = with maintainers; [ figsoda ]; }; } </ins>

Discussion:
jello: Filter JSON and JSON Lines data with Python syntax jello is similar to jq in that it processes JSON and JSON Lines data except jello uses standard python dict and list syntax. JSON or JSON Lines can be piped into jello via STDIN or can be loaded from a JSON file or JSON Lines files (JSON Lines are automatically slurped into a list of dictionaries). Once loaded, the data is available as a python list or dictionary object named ‘_’. Processed data can be output as JSON, JSON Lines, bash array lines, or a grep-able schema. Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, windows (anything with Python)
Change:
, stdenv , fetchurl , appimageTools <ins> , unzip </ins> , makeWrapper # Notice: graphs will not sync without matching upstream's major electron version #         the specific electron version is set at top-level file to preserve override interface.

Discussion:
Project description but only for x86_64-linux. Would be great if it could be packaged also for aarch64-darwin. Builds exist in the loges project for multiple platforms already. Metadata homepage URL: source URL: license: AGPL-3.0 platforms: linux (already exist), aarch64-darwin
Logseq is quite good. I have support based on the current unstable version. It works, but a few issues are preventing me from submitting a PR: alert stating 'This file was downloaded on an unknown date.' prevents me from opening the app. I have to allow it in . I am not sure what causes this, maybe related: don't know how to remove the internal git, as the Linux version does.
Change:
{ lib , python3 , openssl <ins> , fetchpatch </ins> # Many Salt modules require various Python modules to be installed, # passing them in this array enables Salt to find them. , extraInputs ? []

Discussion:
nicely describes the issue and the fix Steps to reproduce the behavior: salt on to run it errors salt working and may be of interest to ;) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
Change:
sha256 = "sha256-vFoSH/vJS1FxrV6+Ab5CdG1Qqnl8lUmkY5iUoWdJRDs="; }; <del> dontDisableStatic = enableStatic; configureFlags = lib.optional enableStatic "LDFLAGS=-static"; </del> CFLAGS = lib.pipe (lib.attrNames dflags) [ (builtins.map (name: "-D${name}="${dflags.${name}}"")) (lib.concatStringsSep " ")

Discussion:
Steps to reproduce the behavior: Broken from , worked in . Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
If I'm reading the log correctly, this fails already when building the glibc dependency, doesn't it? After some experimentation, I came up with the changes in
Very cool, that solves it! Thank you :)
Change:
''; */ <del> meta = { </del> <ins> meta = with stdenv.lib; { </ins> description = "GNUnet, GNU's decentralized anonymous and censorship-resistant P2P framework"; longDescription = ''

Discussion:
The release and git versions show gpl2+. It should be Affero GPL v3 or later. GNUnet is free software released under the GNU Affero General Public License (v3 or later).
Change:
--argstr libPath "$libPath"  --argstr pkgsLibPath "$pkgsLibPath"  --argstr nixosPath "$nixosPath"  <del> --arg modules "[ $modules ]"  </del> <ins> --arg modules "import $modulesPath"  </ins> --argstr stateVersion "${options.system.stateVersion.default}"  --argstr release "${config.system.nixos.release}"  $nixosPath/lib/eval-cacheable-options.nix > $out 

Discussion:
When building nixos top level, will be too long to consume. I don't have a minimal config to generate the drv but here is an example: No Error Related code: Not entirely sure which version is causing the failure --- used to be able to built on but seems to be failing afterwards. Will update once find the exact hash. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The module list grows over time, so it would make sense to hit the limit at some point. I suppose you could write the expression to a file and pass to fix the problem. I don't get why this derivation is called "lazy" though.
Change:
]; meta = with lib; { <ins> changelog = "https://github.com/googleapis/google-auth-library-python-oauthlib/blob/v${version}/CHANGELOG.md"; </ins> description = "Google Authentication Library: oauthlib integration"; homepage = "https://github.com/GoogleCloudPlatform/google-auth-library-python-oauthlib"; license = licenses.asl20; <ins> mainProgram = "google-oauthlib-tool"; </ins> maintainers = with maintainers; [ terlar ]; }; }

Discussion:
Package name: Latest released version: 2.27.0 <!-- Search your package here: --- Current version on the unstable channel: 2.21.0 Current version on the stable/release channel: 2.21.0 <!-- 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:
sha256 = "0psw67mzysdb8fkh8xpcwicm7z94k8plkcc8ymxyvl6inshq0mc7"; }; <ins> # Revert after https://github.com/NixOS/nixpkgs/issues/125008 is # fixed properly patches = [ ./cmake-fix-libxml2-find-package.patch ]; </ins> nativeBuildInputs = [ cmake flex

Discussion:
Describe the bug fails to build on master/release-21.05. The build failure ( is not found anymore by cmake) appeared with the update of from 2.9.10 to 2.9.12. Addressing CC
Change:
"hash": "sha256:1dfbbydmayfj9npx3z0g38p574pmcx3qgs49dv0npigl48wd9yvq" }, "6.1": { <del> "version": "6.1.65", "hash": "sha256:02mj394ina3npp6qqinc4pc6afp5pg1rlbjc90g4p902d29jjwj0" </del> <ins> "version": "6.1.66", "hash": "sha256:030sxwzqlf9jg57j1hvd46ffkc9yfplbk3b81faycfa2dk6n57j1" </ins> }, "5.15": { <del> "version": "5.15.141", "hash": "sha256:1yicgvq413801qrfzr0rdzwgg45dszrvfd6y9dmrhak9bk36lvck" </del> <ins> "version": "5.15.142", "hash": "sha256:0xjn16b02f8d6c0m8vrbmk85kdyfy8m46s80rnkb0nnwfx9cjxld" </ins> }, "5.10": { <del> "version": "5.10.202", "hash": "sha256:12zs2bz2plps6xp80sdg36zkyr00rf5l5c85jl4dd7b9klly04ij" </del> <ins> "version": "5.10.203", "hash": "sha256:0xr8p7kfr1v3s41fv55ph0l8d9s2p146dl2fh3r2y09lrvwwxssn" </ins> }, "5.4": { <del> "version": "5.4.262", "hash": "sha256:1p34x33gkvpv26zcrpx1i6dr7dknyxj8gnp6caqb8sj58h3slgkx" </del> <ins> "version": "5.4.263", "hash": "sha256:1y1mfwjsilrx8x8jnjlyh8r9zlygjjqdf7pay92jv2qijjddpl2h" </ins> }, "4.19": { <del> "version": "4.19.300", "hash": "sha256:0ilksl94gjpc4pzc90swfawsl8lvibpq14nkaxzl0831i219ahd8" </del> <ins> "version": "4.19.301", "hash": "sha256:1fr05fl8fyyjgsqj8fppd5v378d7sazvpqlq4sl875851fd9nmb2" </ins> }, "4.14": { <del> "version": "4.14.331", "hash": "sha256:03sk82dgvccv70i3hy8gf2hw0n4m305f7rxjw93p7jnjrbpdrp1r" </del> <ins> "version": "4.14.332", "hash": "sha256:1f4q0acbp917myjmgiy4haxp78yak5h1rj5g937r6mkykwb6nb14" </ins> }, "6.6": { <del> "version": "6.6.4", "hash": "sha256:0i9ym5nqf704iz5674k66kn9a5hkm0y0sdhqy5c6v39xr5h9dr29" </del> <ins> "version": "6.6.5", "hash": "sha256:17miac3h4kvj4yyf042qsmpsivpq243db5v0ay6233d6aic7k4kw" </ins> } }

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:
version = "238"; name = "systemd-${version}"; <ins> # When updating, use https://github.com/systemd/systemd-stable tree, not the development one! # Also fresh patches should be cherry-picked from that tree to our current one. </ins> src = fetchFromGitHub { owner = "NixOS"; repo = "systemd"; <del> rev = "243d65d38f2df82d4a39f6a9970337803dff65a1"; sha256 = "098hxlkh6q17rxa178adylksxnnd4x9rxb8amjnlbiydcc6kaa5n"; </del> <ins> rev = "3a439bcdb5706dbb44215ef4e70f07b09aaac040"; sha256 = "0qkk5891068pkxmxqvm07bwl597i8lfp89c23yxp11m21cjq0f4b"; </ins> }; outputs = [ "out" "lib" "man" "dev" ];

Discussion:
containers started with (or related options) only see a loopback interface, the desired interface to the host is missing. Same applies to containers created by . Problem exists with linux 4.14 and systemd 238. With linux 4.9 and systemd 238, container networking looks ok. See also discussion in /cc Any of these: fails, container complains about missing interface Try to start a container created by . manual tests with show only loopback interface in container. 03pre131587..
For reference, the current 18.03 branch downgraded systemd to 237 (mainly due to this), but the big 18.03 channel is still with systemd-238 ATM.
One thing I observed is that we compile systemd (and glibc etc. ) with the latest linux-headers (currently 4.15), no matter what kernel version actually runs on the system. This may not work according to : means that a program built against a C library using older kernel headers should run on a newer kernel (although it may not have access to new features), but a program built against newer kernel headers may not work on an older kernel_. Don't know if that is relevant for this issue but will do a little experiment.
Oh, from discussion here I understood otherwise, which is why it was deemed safe to bump the headers. /cc IIRC.
After rebuilding with kernel headers downgraded to 4.14, the issue is still there - so that's not the cause.
We pass to glibc... I wouldn't be completely surprised if things still break with that, but it's not expected at least :grinning:
I can confirm it on Arch Linux - this bug is same with kernel 4.14 and systemd 238. With kernel 4.15 all works normaly.
Thank you I will open an upstream systemd issue for this.
Opened
There's a proposed fix in systemd/systemd (not yet merged). I just tested it on NixOS - seems to fix this issue. Will make a PR for nixos/systemd when the fix is merged upstream.
fixed in
Change:
<ins> #!/usr/bin/env nix-shell #!nix-shell -I nixpkgs=./. -i bash -p curl jq common-updater-scripts set -eo pipefail cd "$(dirname "${BASH_SOURCE[0]}")" new_version="$(curl -s "https://api.github.com/repos/azure/bicep/releases?per_page=1" | jq -r '.[0].name')" old_version="$(sed -nE 's/s*version = "(.*)".*/1/p' ./package.nix)" if [[ "$new_version" == "$old_version" ]]; then echo "Already up to date!" exit 0 fi cd ../../../.. update-source-version bicep "${new_version//v}" nix-build -A bicep.fetch-deps --no-out-link </ins>

Discussion:
Project description Bicep is a declarative language for describing and deploying Azure resources It can also be used as an extension of tool. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
}; tests = { inherit (nixosTests.terminal-emulators) gnome-terminal lxterminal mlterm roxterm sakura stupidterm terminator termite xfce4-terminal; <ins> blackbox-terminal = blackbox-terminal.override { sixelSupport = true; }; </ins> }; };

Discussion:
Steps to reproduce the behavior: blackbox-terminal blackbox uses vte with , this change probably broke it Please run and paste the result. but that's irrelevant as i'm trying to build the latest master. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
inherit (darwin.apple_sdk.frameworks) Carbon IOKit; }; <del> cemu = qt5.callPackage ../applications/science/math/cemu { stdenv = gcc9Stdenv; }; </del> <ins> cemu-ti = qt5.callPackage ../applications/science/math/cemu-ti { }; </ins> cider = callPackage ../applications/audio/cider { };

Discussion:
See title Steps to reproduce the behavior: Fails compilation on x86_64-linux with It should build. Or it should be marked as broken. Please run and paste the result.
Would it make sense to use the opportunity and rename it to along the way (to deconflict with which could be )? It seems to me that nobody is currently relying on this to work for their nix configurations since it stopped properly building 4 months ago (I don't even think it builds in 22.05?).
Change:
"zsh_cv_sys_dynamic_strip_lib=yes" ]; <ins> preConfigure = '' # use pkg-config instead of pcre-config configureFlagsArray+=("PCRECONF=''${PKG_CONFIG} libpcre") ''; </ins> # the zsh/zpty module is not available on hydra # so skip groups Y Z checkFlags = map (T: "TESTNUM=${T}") (lib.stringToCharacters "ABCDEVW");

Discussion:
Steps to reproduce the behavior: nixpkgs/#pkgsCross.armv7l-hf- () Not sure what's going on here, looking at zsh looks like it should build for ARM without any special handling. <!-- 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.
Most likely something related to glibc, since building with musl (at least through pkgsStatic) works. Also since it can't find any of these during configure:

This is from nixos-unstable current. For some reason, I get build failures with ZSH. This is with a nixpkgs (system=x86_64-linux) and nixpkgs.crossSystem set to . This seems to be the same failure (I checked, its the same derivation): Steps to reproduce the behavior: ... ... ... A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
couldn't fix it. I'll leave this assigned to myself so i remember to take a another shot at it in ~6 months
Fixed by