jiebi/CodeConvo huggingface dataset:
Change:
lib = lib.extend (final: prev: { nixosSystem = { modules, ... } @ args: import ./nixos/lib/eval-config.nix (args // { <del> modules = modules ++ [ { system.nixos.versionSuffix = </del> <ins> modules = let vmConfig = (import ./nixos/lib/eval-config.nix (args // { modules = modules ++ [ ./nixos/modules/virtualisation/qemu-vm.nix ]; })).config; vmWithBootLoaderConfig = (import ./nixos/lib/eval-config.nix (args // { modules = modules ++ [ ./nixos/modules/virtualisation/qemu-vm.nix { virtualisation.useBootLoader = true; } ]; })).config; in modules ++ [ { system.nixos.versionSuffix = </ins> ".${final.substring 0 8 (self.lastModifiedDate or self.lastModified)}.${self.shortRev or "dirty"}"; system.nixos.revision = final.mkIf (self ? rev) self.rev; <ins> system.build = { vm = vmConfig.system.build.vm; vmWithBootLoader = vmWithBootLoaderConfig.system.build.vm; }; </ins> } ]; });

Discussion:
Describe the bug It was left out being implemented in the initial PR , but it's a very useful feature for nixos development and endusers. I do understand it's nothing can't do, but it's a useful wrapper. cc
See for an attempt at adding support for this.
Change:
inherit (darwin.apple_sdk.frameworks) Security; }; <del> gpu-burn = callPackage ../applications/misc/gpu-burn { }; </del> <ins> gpu-burn = callPackage ../applications/misc/gpu-burn { # gpu-burn doesn't build on gcc11. CUDA 11.3 is the last version to use # pre-gcc11, in particular gcc9. cudatoolkit = cudaPackages_11_3.cudatoolkit; stdenv = gcc9Stdenv; }; </ins> greg = callPackage ../applications/audio/greg { pythonPackages = python3Packages;

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking python3Packages.jaxlibWithCuda. python3Packages.jaxlibWithCuda maintainers cc: maintainers cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:
I'm observing this error with many more packages (e.g. ). I'd expect it would've been introduced introduced elsewhere than in openscad commit?
I just bisected a similar bug (dm-tree failure) to
I'm not sure what to do about this... It seems like the kinda of thing people won't want to rollback, but it's also breaking a loooooot of things. cc
Can't reproduce, no build failure on my end. Hydra also has a cached built copy.
I think it's only the version that's failing
I'll see what happens if we bump in
Hopefully it is only a gcc mismatch issue.
RE: Ok, actually tensorflow and jaxlib are still pinned to and override to , so they're all pulling in . Idk about unpinning tensorflow, but I'm pretty sure we should be safe to switch jaxlib to the default cuda packages
As far as the error message goes it seems like it wants LLVM clang rather than GNU g++.
That's a good point. I think we should unpin jax from needing to use the same versions as TF. This seemed like a good idea at the time (I advocated for it), but it's proven to be a PITA since then. TF's version constraints are just so outdated. would you be opposed? I suspect that this was caused by the GCC bump, but I'm not 100% certain yet. I'm currently bisecting a different failure, but once that's done I'll try to debug this further!
Unpinning jax from the old cudaPackages and bumping the new cuda packages to gcc11 I get no more missing symbols, but I fail with:
Thanks for taking a stab at that Just to confirm: is that error within glibc or is it indicating a misuse of glibc APIs?
would you mind the derivation that you've been using? I'm curious to reproduce
good catch, the error was from: I was trying to build with updating and removing for jaxlib and jaxlib-build
Created an issue upstream:
Change:
githubId = 11614750; name = "Alexander Sharov"; }; <ins> kwaa = { name = "藍+85CD"; email = "kwa@kwaa.dev"; matrix = "@kwaa:matrix.org"; github = "kwaa"; githubId = 50108258; keys = [{ fingerprint = "ABCB A12F 1A8E 3CCC F10B  5109 4444 7777 3333 4444"; }]; }; </ins> kwohlfahrt = { email = "kai.wohlfahrt@gmail.com"; github = "kwohlfahrt";

Discussion:
Project description Self-hosted & Fully-automated ActivityPub Bridge for Static Sites. Metadata homepage URL: source URL: license: agpl3Only platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'll try to make a PR.
Change:
<ins> { lib , fetchFromGitHub , python3 }: python3.pkgs.buildPythonApplication rec { pname = "castero"; version = "0.9.5"; pyproject = true; src = fetchFromGitHub { owner = "xgi"; repo = "castero"; rev = "v${version}"; hash = "sha256-6/7oCKBMEcQeJ8PaFP15Xef9sQRYCpigtzINv2M6GUY="; }; nativeBuildInputs = with python3.pkgs; [ setuptools wheel ]; propagatedBuildInputs = with python3.pkgs; [ requests grequests cjkwrap pytz beautifulsoup4 lxml mpv python-vlc ]; nativeCheckInputs = with python3.pkgs; [ pytestCheckHook ]; pytestFlagsArray = [ "tests" ]; disabledTests = [ "test_datafile_download" ]; pythonImportCheck = [ "castero" ]; # Resolve configuration tests, which access $HOME preCheck = '' export HOME=$(mktemp -d) ''; # Satisfy the python-mpv depedency, which is mpv within NixOS postPatch = '' substituteInPlace setup.py --replace-fail "python-mpv" "mpv" ''; # VLC currently doesn't support Darwin on NixOS meta = with lib; { mainProgram = "castero"; description = "TUI podcast client for the terminal"; homepage = "https://github.com/xgi/castero"; license = licenses.mit; platforms = platforms.linux; maintainers = with maintainers; [ keto ]; }; } </ins>

Discussion:
Project description TUI podcast client for the terminal Metadata homepage URL: - source URL: license: mit platforms: unix, linux, darwin, ...
Change:
hugs = callPackage ../development/interpreters/hugs { }; <del> inherit (javaPackages) openjfx11 openjfx15 openjfx17 openjfx19 openjfx20 openjfx21; </del> <ins> inherit (javaPackages) openjfx11 openjfx15 openjfx17 openjfx19 openjfx20 openjfx21 openjfx22; </ins> openjfx = openjfx17; openjdk8-bootstrap = javaPackages.compiler.openjdk8-bootstrap;

Discussion:
Project description OpenJDK 22 was released on 19-MAR-2024. The OpenJDK project has been releasing Early Access (EA) binaries for many months now. It would be nice to be able to install OpenJDK 22 as a Nix package and also to begin development of dependent Nix packages (e.g. ) Metadata homepage URL: source URL: (update: is open now) license: GPL with Classpath Exception platforms: unix, linux, darwin, others I'm fairly new to Nix (but loving it so far) so I'm not 100% sure this whether this should be a "new package request" (as Nix keeps multiple versions of OpenJDK available as different packages) or a "package update request" (since jdk22 is an updated version of jdk21.) If I need to change this or anything else in the issue please let me know and I will try to fix it.
Change:
, libnotify , libX11 , libxcb <ins> , headless ? false </ins> }: stdenv.mkDerivation rec {

Discussion:
Project description Currently there is a package for boinc, but it comes with a GUI manager. For a headless server it would be nice to have a package without graphical dependencies as an option. Unfortunately, I have no experience in creating packages myself, but I found these links that might be useful: General build instructions: Arch Package: Metadata homepage URL: source URL: license: gpl3, lgpl3 platforms: unix, linux, darwin
Change:
"acme/.lego/accounts/${accountHash}" ]; <ins> ReadWritePaths = commonServiceConfig.ReadWritePaths ++ webroots; </ins> # Needs to be space separated, but can't use a multiline string because that'll include newlines BindPaths = [ "${accountDir}:/tmp/accounts"

Discussion:
Since , all except gets mounted in a read-only fashion. This behaviour will break the existing acme deployments having a set outside of . In my personal case, I have the webroot served by my main nginx service. Meaning: After , the cert renewal fails with: The fix I personally went with was to add my webroot to the by overriding the service config. That's however not a proper fix for NixPkgs. As it is, we'll silently break some already existing deployments. While that's something acceptable for nixos-unstable, I feel like we have to adopt a better migration path before the next stable release. I have three options in mind: could revert the hardening option to . could add the webroots to the config. Could this backfire in some way? could trigger a assertion error warning the user that some of their webroots are not in the s and instruct them about how to fix the issue. I did not manage do decide which of these solutions is the best. What do you think? cc
I think we should go that route, I can't imagine this to backfire, since it could write to that location before, too.
I think suggestion 2 is what I'd go for. is not an ideal option as we would rather keep the module as secure as possible. Adding all the unique webroots not under /var/lib/acme should be pretty easy to automate.
:+1: ack. I'll send a PR shortly.
Oh cool ok!
Thanks for your work, but I have a similar issue. Seems a regression occurs. Here is the log: Here is my config: If I set to , it works well. But if I set to a non-existing dir like , error occurs. In addition, a non-existing will make all other services whose is under fail. The reason may be that all services have due to .
Change:
GEM remote: https://rubygems.org/ specs: <del> execjs (2.3.0) json (1.8.2) libv8 (3.16.14.11) ref (1.0.5) sass (3.4.11) therubyracer (0.12.1) libv8 (~> 3.16.14.0) ref uglifier (2.7.0) execjs (>= 0.3.0) json (>= 1.8.0) </del> <ins> execjs (2.7.0) ffi (1.9.23) rb-fsevent (0.10.3) rb-inotify (0.9.10) ffi (>= 0.5.0, < 2) sass (3.5.6) sass-listen (~> 4.0.0) sass-listen (4.0.0) rb-fsevent (~> 0.9, >= 0.9.4) rb-inotify (~> 0.9, >= 0.9.7) uglifier (4.1.10) execjs (>= 0.3.0, < 3) </ins> PLATFORMS ruby DEPENDENCIES sass <del> therubyracer </del> uglifier <ins> BUNDLED WITH 1.14.6 </ins>

Discussion:
The consul-ui packages currently fails to build on 18.03 and master. On 18.03, applying the following patch causes the build to succeed: however, on master, it fails with: I've tried various things including using different versions of ruby and bundler, but none have solved the issue.
Change:
owner = "paul-gauthier"; repo = "aider"; rev = "refs/tags/v${version}"; <del> hash = "sha256-e0Fqj67vYt41Zbr1FN2fuLp6cHRius8RtacBHLgB9dM="; </del> <ins> hash = "sha256-ErDepSju8B4GochHKxL03aUfOLAiNfTaXBAllAZ144M="; </ins> }; pythonRelaxDeps = true;

Discussion:
A small difference in the dependencies used by aider and nixpkgs causes aider to crash. aider 0.56.0 something should get a stack overflow See <!-- 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]:
was closed by mistake so opened this
Thanks for opening this issue. Discussion started here It is clear that v1.44.22 of is what causes the issue but I'm not sure what could be done. maybe you have an idea?
There is an open issue in the repo, we have to wait for the dependencies to be updated upstream unfortunately. On the next update of this dependency ill be sure to try to run aider. Sorry for the inconvenience !
Why don't you use ?
the issue on aider's repo was closed the fix is to not use the wrong version of litellm :sweat:
it's not so simple for python packages. each one is a forest of carefully balanced dependencies.
Latest aider update matches with the latest litellm update, so we should be good in a couple of days
Change:
''; passthru.tests = testers.testVersion { <del> version = "4.9.5"; # required for passing tests, TODO: remove when release bump </del> package = quickemu; }; meta = { description = "Quickly create and run optimised Windows, macOS and Linux virtual machines"; homepage = "https://github.com/quickemu-project/quickemu"; <ins> changelog = "https://github.com/quickemu-project/quickemu/releases/tag/${finalAttrs.version}"; </ins> mainProgram = "quickemu"; license = lib.licenses.mit; maintainers = with lib.maintainers; [

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:
zstd ]; <del> postPatch = '' patchShebangs tools/get_wb_version.sh ''; </del> # GCC 13: error: 'int64_t' in namespace 'std' does not name a type # when updating the version make sure this is still needed env.CXXFLAGS = "-include cstdint";

Discussion:
Steps to reproduce the behavior: mysql-workbench-8.0.36 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Problem introduced in Thanks for reporting, I'll try to fix it
Change:
]; postPatch = '' <del> patchShebangs install.sh clean-old-theme.sh </del> <ins> patchShebangs install.sh </ins> ''; installPhase = ''

Discussion:
Package name: colloid-gtk-theme Latest released version: 2022-11-11 <!-- Search your package here: --- Current version on the unstable channel: 2022-07-18 Current version on the stable/release channel: 2022-07-18 <!-- 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.
Change:
src = builtins.getAttr source { "default" = common.src; # latest release <del> "vim-nox" = { # vim nox branch: client-server without X by uing sockets # REGION AUTO UPDATE: { name="vim-nox"; type="hg"; url="https://code.google.com/r/yukihironakadaira-vim-cmdsrv-nox/"; branch="cmdsrv-nox"; } src = (fetchurl { url = "http://mawercer.de/~nix/repos/vim-nox-hg-2082fc3.tar.bz2"; sha256 = "293164ca1df752b7f975fd3b44766f5a1db752de6c7385753f083499651bd13a"; }); name = "vim-nox-hg-2082fc3"; # END }.src; </del> }; patches = [ ./cflags-prune.diff ] ++ stdenv.lib.optional ftNixSupport ./ft-nix-support.patch;

Discussion:
in master (at ) is built from a patched source tree for vim 7.3 from 2012 which was never updated. The resulting package's name is vimconfigurable-8.1.0001 but it actually contains vim 7.3.315. Unfortuately there's no newer version for the source at the listed URL. should either be updated or dropped from nixpkgs. Given that nobody has bothered to update it since 2012, I vote to drop it. (This issue surfaced when removed the pin of to lua 5.1 and broke because the old vim 7.3 is incompatible with lua 5.2).
Let's drop this now since no one has shown any interest.
Change:
"--with-qt-bindir=${qtbase.dev}/bin:${qttools.dev}/bin" ]; <del> # fix "Killed: 9  test/test_bitcoin" # https://github.com/NixOS/nixpkgs/issues/179474 hardeningDisable = lib.optionals (stdenv.isAarch64 && stdenv.isDarwin) [ "fortify" "stackprotector" ]; </del> checkInputs = [ python3 ]; doCheck = true;

Discussion:
the build ends up with:
We can trivially workaround this by disabling the tests for aarch64-darwin: but it would be much better to understand the underlying issue and fix that instead
ping
Fixed by
follow-up fix in PR:
I can see two PRs disabling hardening features, and , but neither have an explanation of the problem, or why turning off hardening features was the best / correct fix? Can you explain further? I see the workarounds are still present: and It would be great to know why this is necessary for Nix. These hardening features work fine for native builds, and are used in our release binaries.
This used to fix "Killed: 9" error while running the tests, but it seems this is not helping anymore. My guess is that code signing is somehow messing with the test binaries.
I think the hardening feature was broken when building with gfortran. The issue has been fixed recently.
Still broken with "Killed: 9". Looks like binaries are not signed before .
As can be seen here, the issue is intermittent and does not appear all the time: This makes it harder to debug.
Fix in
Change:
fuse.section.md ibus.section.md kakoune.section.md <ins> krita.section.md </ins> linux.section.md locales.section.md etc-files.section.md

Discussion:
Krita 5 complains that it cannot find the G'Mic plugin. Steps to reproduce the behavior: Krita and the G'Mic plugin by adding and to in Krita a new image the menu item Filter→Start G'MIC-Qt will complain, via a modal dialog, that it cannot load the plugin. the menu item Settings→Configure Krita… should be a "G’Mic plugin" section in the left-hand sidebar, but there is not. For there to be a Krita setting to specify the path to the G'Mic plugin. The explains the correct behaviour.
Starting from the package won't work with Krita. Krita team forked and Krita will only work with that fork: It would take some effort to implement the build process mentioned in the README since cmake and make need to be invoked multiple times. (Probably need to manually write the whole and )
Is it possible to maintain a separate krita-gmic package like arch linux does?
It is possible but making it a separate package probably wouldn't make it easier to implement. We just need someone to implement the build process I linked above in nix (sorry I don't have time to do it)
Making some minor changes to you can build the krita plugin: I've not yet been able to have krita load the plugin though. I've tried creating a symlinkJoin'ed version with the plugin, that does not work :confused: Krita is not logging enough information about where it tried to load the plugin for me to be able to deduce what is going wrong.
Do you think the Krita fork of gmic-qt should be integrated in the definition at ? I was originally afraid modifying it now would not be worth it because the two versions might deviate too much from one another.
If you want to remove the original gmic-qt and change it to krita's fork, I believe it will conflict with the previous one, and I would therefore vote against it If you want to keep the fork along with the original, it's fine! You can use overrideAttrs magic in order to reuse the previous expression. Look at as an example for inspiration.
Option 1 is terrible, I'd never ask for that :smiley:.

I was asking if krita's gmic-qt should be included as a "variant" in , effectively does the same as option 2 <details<summaryLike this</summary</detailsI think it's best to keep it as a completely separate package, because both packages will never have matching versions.
So close! I got the "Q'MIC-qt for Krita" window to open by manipulating : ! Unfortunately it segfaults the moment I try to use any of the filters: Progress at
Change:
mkDerivation rec { pname = "semantik"; <del> version = "1.2.7"; </del> <ins> version = "1.2.10"; </ins> src = fetchFromGitLab { owner = "ita1024"; repo = "semantik"; rev = "semantik-${version}"; <del> sha256 = "sha256-aXOokji6fYTpaeI/IIV+5RnTE2Cm8X3WfADf4Uftkss="; </del> <ins> hash = "sha256-qJ6MGxnxXcibF2qXZ2w7Ey/aBIEIx8Gg0dM2PnCl09Y="; </ins> }; patches = [ <del> (fetchpatch { name = "fix-kdelibs4support.patch"; url = "https://gitlab.com/ita1024/semantik/-/commit/a991265bd6e3ed6541f8ec099420bc08cc62e30c.patch"; sha256 = "sha256-E4XjdWfUnqhmFJs9ORznHoXMDS9zHWNXvQIKKkN4AAo="; }) </del> ./qt5.patch ];

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 1.2.7 Current version on the stable/release channel: 1.2.7 <!-- 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 previous commit: <!-- 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:
<del> { stdenv, binutils-unwrapped, cctools }: </del> <ins> { stdenv, binutils-unwrapped, cctools, llvm }: </ins> # Make sure both underlying packages claim to have prepended their binaries # with the same targetPrefix.

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:
+    # no need to restore +    pass def footer(l=79): <del> print("n" + "-" * l + "n") @@ -233,74 +215,12 @@ def remove_complete_msg(): footer() </del> <ins> @@ -276,76 +254,13 @@ def remove_complete_msg(): </ins> def deploy_daemon(): -    print("n" + "-" * 21 + " Deploying auto-cpufreq as a daemon " + "-" * 22 + "n")

Discussion:
Describe the bug I believe the auto-cpufreq daemon should start on boot if enabled. To Reproduce auto-cpufreq daemon: . the system. . auto-cpufreq as dead/inactive. Expected behavior auto-cpufreq service should be started on boot. Additional context I was using the unstable service in 20.09 and it worked as expected. In 21.05 stable, the service starts dead/inactive and my system is very slow. I manually start the service and I'm back to the NixOS I know and love. I was able to fix this by adding the following to my configuration: Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(pnelson): channels(root): nixpkgs: Maintainer information:
Sorry for being late, should fix this.
I have the exact same issue now, on 23.11.
Same here, also facing this problem on 23.11...
Thought this might be caused due to some false overwrites in the module config, so I decided to try out rewriting the systemd service. Doesn't work either...
For others who might still be hitting this, I thought I was too. When checking the logs I saw that power-profiles-daemon was starting up, causing auto-cpufreq to shut down. I fixed this by adding: From looking at this code, and be kind with me here since I'm a nix beginner, it is .  I think the best action would be to add an assertion to give users a prompt like with tlp. If this looks correct I can open a PR for it
Change:
{ lib , buildNpmPackage , fetchFromGitHub <ins> , runCommand , web-ext </ins> }: buildNpmPackage rec {

Discussion:
It looks like , so the program crashes on every run. See . No crash. system: host os: multi-user?: sandbox: version: channels(root): channels(username): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: