jiebi/CodeConvo huggingface dataset:
Change:
conf = if cfg.configFile == null then prettyJSON cfg.configuration else cfg.configFile; <ins> validateConfig = file: pkgs.runCommand "validate-loki-conf" { nativeBuildInputs = [ pkgs.grafana-loki ]; } '' loki -verify-config -config.file "${file}" ln -s "${file}" "$out" ''; </ins> in { <del> ExecStart = "${cfg.package}/bin/loki --config.file=${conf} ${escapeShellArgs cfg.extraFlags}"; </del> <ins> ExecStart = "${cfg.package}/bin/loki --config.file=${validateConfig conf} ${escapeShellArgs cfg.extraFlags}"; </ins> User = cfg.user; Restart = "always"; PrivateTmp = true;

Discussion:
loki's configuration should be verified by the derivation before deploying with the parameters. <!-- 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]:
I've been using this gist: But I've been receiving these validation errors: For now I've set to to bypass the validation as it does work for me. Just a heads-up to whoever is looking here.
Do you think you could have a look at this?
thanks for sharing your config in that gist. That's incredibly helpful for reproducing and understanding your issue. I don't see how those validation errors are false positives though. All those keys/fields/values that throw errors are have been deprecated and removed from loki . See or . What makes me believe that this isn't a false positive is, that even if you skip the validation, will not be able to start due to the same error: and your workaround setting does not work either, because isn't a valid flag: See
I've not looked into Loki logs to see if there are errors mentioned but my dashboards all still worked and I took that as an indicator that everything was still OK. Thank you for linking to the breaking changes documentation, this is also helpful for other broken programs I have at the moment.
Updated my configuration and your comment was spot on, indeed it was not working with that setup and the trick didn't work as I thought, I just was not informed enough on this loki/promtail service :sweat_smile: Thanks for the help
Change:
"Terminus" = "0g2ybs225fwxmvwfnanc32jc2lfnag3agmliv1vrb5mxyqzm53gj"; "Tinos" = "077n4k6yh4qbirfkl02zqn3057kymspr10zcbfkf4ldvifa36pjd"; "Ubuntu" = "1lzdrgb8vk5dwicxhvkgbain5phf88g3zgv5ya2ihh052xsl3qih"; <ins> "UbuntuMono" = "0wa8ri7f3g8vwd194q812qh8nzplnmhl5ak0yhgilmm44s46ad0h"; </ins> "VictorMono" = "18z92kwggfqwrd5m09yda55hcb4b159278lps6f9hr8icwki6v9q"; }

Discussion:
Describe the bug Since the recent change to the way nerd-fonts are handled (PR ), a few fonts from nerd-fonts are not downloaded. To Reproduce Simply install the nerd-fonts, some part of it won't be downloaded such as "InconsolataGo" and "UbuntuMono". Expected behavior All fonts should be specified in this file : , for now some are missing.
cc
It's very important to ping the maintainers of the package so they can see the bug.
Change:
homepage = "https://github.com/mozilla/sccache"; maintainers = with maintainers; [ doronbehar ]; license = licenses.asl20; <del> platforms = [ "x86_64-linux" ]; </del> }; }

Discussion:
Describe the bug It looks like the was to the package, which is Linux-only. Later, a PR was accepted that marked the entirety of as Linux-only when it absolutely works on macOS and probably (though I don't run them) BSD variants. This seems like an incorrect way to include the utility and instead should have been included as a separate package to avoid breaking this package for non-Linux operating systems. To Reproduce Steps to reproduce the behavior: on a macOS machine with an up-to-date unstable channel. Expected behavior should be installable on its supported platforms, in this case . Metadata Please run and paste the result. Maintainer information:
Build currently fails on darwin:
Related:
Change:
, python , mkDerivation , stdenv <del> , isPy3k </del> }: let compyte = import ./compyte.nix {

Discussion:
Describe the bug Not able to install pycuda. Error To Reproduce Install pycuda Expected behavior install pycuda with dependencies Metadata Please run and paste the result.
Is nobody having this issue it seems is not solved :(
I'm having this issue, incoming PR. Likely half of the problem is that the cudatoolkit is pinned to 7.5 and cuda root is not passed during the build process, which is not compatible with newer cards. The other half of the problem is that python3 boost isn't being linked. I see boost is mentioned as not being necessary for pycuda in the docs, so I'm wondering if we can just remove it.
try and let me know if it works for you
Change:
fi if [ "${selfContainedBuild-}" ]; then <del> dotnetBuildFlags+=("--self-contained") </del> <ins> dotnetBuildFlags+=("-p:SelfContained=true") </ins> else <del> dotnetBuildFlags+=("--no-self-contained") </del> <ins> dotnetBuildFlags+=("-p:SelfContained=false") </ins> fi if [ "${version-}" ]; then

Discussion:
no longer builds Steps to reproduce the behavior: on in Expect to build without errors. Not applicable.
Hmm, looks like the abd flags are available only for .NET 6 and newer. My bad, I'll look into fixing it.
I made a PR that fixes it, as well as other packages that have broken.
Change:
homepage = "https://wiki.gnome.org/Projects/gspell"; license = licenses.lgpl21Plus; maintainers = teams.gnome.members; <del> platforms = platforms.linux; </del> <ins> platforms = platforms.unix; </ins> }; }

Discussion:
Project description CherryTree by Giuspen, currently, we are using version 0.39.4, meanwhile the latest application is on 0.99.37. There's a weird jump of version from 0.39.4 to 0.99.13. I don't know why this happens. Metadata homepage URL: source URL: license: GPL3 + platforms: Linux
Package request is the wrong issue type for this, Out-of-date package report would've been better. ! The package is sadly orphaned so there's no maintainer to ping for this.
Change:
''; }; <del> passwordFile = mkOption { </del> <ins> hashedPasswordFile = mkOption { </ins> type = with types; nullOr str; <del> default = null; </del> <ins> default = cfg.users.${name}.passwordFile; defaultText = literalExpression "null"; </ins> description = lib.mdDoc '' <del> The full path to a file that contains the user's password. The password file is read on each system activation. The file should contain exactly one line, which should be the password in an encrypted form that is suitable for the `chpasswd -e` command. </del> <ins> The full path to a file that contains the hash of the user's password. The password file is read on each system activation. The file should contain exactly one line, which should be the password in an encrypted form that is suitable for the `chpasswd -e` command. </ins> ${passwordDescription} ''; }; <ins> passwordFile = mkOption { type = with types; nullOr (passwdEntry str); default = null; visible = false; description = lib.mdDoc "Deprecated alias of hashedPasswordFile"; }; </ins> initialHashedPassword = mkOption { type = with types; nullOr (passwdEntry str); default = null;

Discussion:
Password hashes, while less sensitive than unhashed passwords, are secrets. We should therefore have a option in that avoids both placing the hashes in the store world-readable and storing the password unhashed.
This is a common misunderstanding due to the bad naming of these options: → string of plaintext password → string of password hash → file containing password hash So, what you want already exists and it's .
Oh wow, indeed. Thanks! Given that the option is named so confusingly and that its description starts with "The full path to a file that contains the user's password." I think we should keep the issue, pending an option rename and a documentation improvement.
Change:
OLLAMA_HOST = cfg.listenAddress; }; serviceConfig = { <del> ExecStart = "${lib.getExe cfg.package} serve"; </del> <ins> ExecStart = "${lib.getExe ollamaPackage} serve"; </ins> WorkingDirectory = "/var/lib/ollama"; StateDirectory = [ "ollama" ]; DynamicUser = true;

Discussion:
Ollama can't discover GPU libraries Steps to reproduce the behavior: this completely not overkill nixos config: Ollama discover GPU libraries and able to use GPU acceleration. Previously I was able to discover GPU libs by running downloaded ollama binary via - But anyway it crushes because it uses ROCM 6.0 while in nixpkgs unstable we still have 5.7.1 <!-- 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]:
This appears to be happening because the ollama service currently only ever builds the ollama package in cpu mode. If my understanding is correct, then should fix this, though gpu support won't be enabled automatically. Once is merged, rocm would be enabled like this, and should work without any other configuration:
Change:
{ config, stdenv, lib, fetchurl, fetchzip, boost, cmake, ffmpeg, gettext, glew , ilmbase, libXi, libX11, libXext, libXrender , libjpeg, libpng, libsamplerate, libsndfile <del> , libtiff, libGLU, libGL, openal, opencolorio, openexr, openimagedenoise, openimageio2, openjpeg, python39Packages </del> <ins> , libtiff, libGLU, libGL, openal, opencolorio, openexr, openimagedenoise, openimageio2, openjpeg, python310Packages </ins> , openvdb, libXxf86vm, tbb, alembic <del> , zlib, fftw, opensubdiv, freetype, jemalloc, ocl-icd, addOpenGLRunpath </del> <ins> , zlib, zstd, fftw, opensubdiv, freetype, jemalloc, ocl-icd, addOpenGLRunpath </ins> , jackaudioSupport ? false, libjack2 <del> , cudaSupport ? config.cudaSupport or false, cudatoolkit </del> <ins> , cudaSupport ? config.cudaSupport or false, cudatoolkit_11 </ins> , colladaSupport ? true, opencollada , spaceNavSupport ? stdenv.isLinux, libspnav , makeWrapper

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 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: blender <!-- The current version can be found easily with the same process as 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: 2.93.5 desired version: 3.1 <!-- 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:
</para> </listitem> <listitem> <ins> <para> <literal>rubyMinimal</literal> was removed due to being unused and unusable. The default ruby interpreter includes JIT support, which makes it reference it's compiler. Since JIT support is probably needed by some Gems, it was decided to enable this feature with all cc references by default, and allow to build a Ruby derivation without references to cc, by setting <literal>jitSupport = false;</literal> in an overlay. See <link xlink:href="https://github.com/NixOS/nixpkgs/pull/90151">#90151</link> for more info. </para> </listitem> <listitem> </ins> <para> The option <option>fonts.enableFontDir</option> has been renamed to <xref linkend="opt-fonts.fontDir.enable"/>. The path of font directory

Discussion:
Describe the bug I'm hunting down packages that reference gcc. One of them is (maintainers: & ). Here's why: The fault is the fact that the build flag doesn't remove all references, as one might expect (EDIT, see: ). I'm up to including this feature, but I was wondering perhaps it'd be legit to disable this feature for the derivation? I opened a PR at (EDIT).
But that would mean gems that require a compiler would no longer work.
The suggestion is for , not . Isn't the derivation that's used to build the gems? According to:
It still has support for gems, so some will fail with gcc. What exactly is the use case for ?
Technically it's not used anywhere, according to .
I'd like to make my - with an overlay. The goal is to make the 1 or 2 pure ruby scripts I have on my system not pull , as they do today.
But what is the reason? You're likely to have a version of ruby that includes gcc on your system anyway, so you don't really save any space. And the use-case would be plain ruby scripts with only the gems that don't require system libraries. We have no users in nixpkgs of presumably because it's rather pointless. And while of course we can strip gcc from rubyMinimal (there's no harm), I'd rather say drop instead.
Not If I'll apply and this overlay: This allows me to not need GCC for for example - which is the only ruby gem I use. For example, run with this PR and that overlay applied: And you should get: And without , (and without the overlay because it would fail) you should get: is the only derivation that needs ruby that I actually use. I've updated the 1st comment in to exemplify this overlay as a possible usecase. Well I tend to agree - even for asciidoctor which should be pretty much a pure ruby gem, it still required and which aren't enabled in current . Hence I tend to agree. OK so I've updated to include a drop to , including release notes and an alias. Waiting for your review :crossed_fingers: .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
sha256 = "1j3048ip691j91rdig6wrlg6i4jdzhszxmz5pi2g7n355rl2w00l"; }; buildInputs = [ DevelPPPort ModuleBuildXSUtil TestException TestFatal TestLeakTrace TestOutput TestRequires TryTiny self.version ]; <ins> perlPreHook = "export LD=$CC"; </ins> NIX_CFLAGS_COMPILE = stdenv.lib.optionalString stdenv.isi686 "-fno-stack-protector"; hardeningDisable = stdenv.lib.optional stdenv.isi686 "stackprotector"; };

Discussion:
! See the . This is to discuss Darwin-specific issues for ZHF. (or more)
Change:
then super.conduit-extra.overrideAttrs (drv: { __darwinAllowLocalNetworking = true; }) else super.conduit-extra; <ins> # https://github.com/cachix/cachix/issues/308 cachix = dontCheck super.cachix; </ins> # Fix Darwin build. halive = if pkgs.stdenv.isDarwin then addBuildDepend super.halive pkgs.darwin.apple_sdk.frameworks.AppKit

Discussion:
Describe the bug See e.g. To Reproduce Running the build locally reproduces it, though I can't see any relation with the reported Nix version on my system. Speculation: some dependency of the cachix build might have "cached" version of the nix daemon running on its builder (and succeeded)? Maintainers will probably know much quicker than me. Notify maintainers
A slight clarification: This appears to just be a test at parsing various Nix versions, not that Nix is installed on whatever machine ran the build/test. This was discussed on livestream last Friday, where he filed this issue: (Here's the part of the stream where it occurred: )
Change:
sha256 = "0rb927zknk9kmhprd8rdr4azql4gn2dp75a36iazx2xhkbqhvind"; }; <ins> patches = [ ./CVE-2015-7747.patch ]; </ins> meta = with stdenv.lib; { description = "Library for reading and writing audio files in various formats"; homepage    = http://www.68k.org/~michael/audiofile/;

Discussion:
There is . I think the fix is , but there was about whether that fixed the problem, so it might be worth a careful look. With any luck I'll have time to look at this in a few hours, but if anyone else wants to take this, comment here.
/cc maintainer:
Today's status: trying to find a patch for 0.3.6 that's supposed to exist; asked at
Probably won't get back to this for 18h or so though... so feel free to grab it :-)
Change:
# fix build with gcc9 NIX_CFLAGS_LINK = lib.optional (stdenv.system == "i686-linux") "-lgcc"; <ins> # Even when statically linking, libstdc++.la is put in dependency_libs here, # and hence libstdc++.so passed to the linker, just pass -lstdc++ and let the # compiler do what it does best.  (libaudiofile.la is a generated file, so we # have to run `make` that far first). # # Without this, the executables in this package (sfcommands and examples) # fail to build: https://github.com/NixOS/nixpkgs/issues/103215 # # There might be a more sensible way to do this with autotools, but I am not # smart enough to discover it. preBuild = lib.optionalString stdenv.targetPlatform.isStatic '' make -C libaudiofile $makeFlags sed -i "s/dependency_libs=.*/dependency_libs=' -lstdc++'/" libaudiofile/libaudiofile.la ''; </ins> patches = [ ./gcc-6.patch ./CVE-2015-7747.patch

Discussion:
Describe the bug Notify maintainers
Had a play with this. Looks like at the moment it's trying to link against , passing causes it to try to link against libstdc++.a from the wrong directory
is present in libtool's lib search paths, , and . Albeit after the directory containing and . I'm not sure if the order is important.
yikes, has , no wonder things are trying to link against
Indeed, if I change 's to point to it all works fine,
This looks like the same error I'm getting in , is this the best solution for this at this point? Unfortunately what I'm trying to build is based on cmake rather than make, so I don't know if this will be directly applicable.
Yeah. The fix for this one here is probably not directly applicable to a cmake project. Weird that someone got into that mess using cmake.
My bad - even though protobuf includes cmake files, the build actually seems to be based on automake(?). However I attempted a similar patch using sed, but the protobuf *.la files don't appear to exist yet by the preBuild hook.
Change:
}; }; <del> pyflakes = buildPythonPackage rec { pname = "pyflakes"; version = "1.3.0"; name = "${pname}-${version}"; src = pkgs.fetchurl { url = "mirror://pypi/${builtins.substring 0 1 pname}/${pname}/${name}.tar.gz"; sha256 = "a4f93317c97a9d9ed71d6ecfe08b68e3de9fea3f4d94dcd1d9d83ccbf929bc31"; }; buildInputs = with self; [ unittest2 ]; doCheck = !isPyPy; force-rebuild = 1;  # fix transient test suite error at http://hydra.nixos.org/build/45083762 meta = { homepage = https://launchpad.net/pyflakes; description = "A simple program which checks Python source files for errors"; license = licenses.mit; maintainers = with maintainers; [ garbas ]; }; }; </del> <ins> pyflakes = callPackage ../development/python-modules/pyflakes { }; </ins> pyftgl = buildPythonPackage rec { name = "pyftgl-0.4b";

Discussion:
Flake8 with Python 3.6 fails to build with System: 17.09pre106916. (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: 17.09pre106916. Sandboxing enabled: build-use-sandbox = false
Try upgrading the pyflakes expression to the latest version
I can produce this same problem using nixpkgs commit (latest master as of this writing).
Change:
after = [ "network.target" ]; partOf = optional config.networking.firewall.enable "firewall.service"; <ins> restartTriggers = [ configFile ]; </ins> path = with pkgs; if config.networking.nftables.enable then [ nftables iproute2 systemd ] else [ iptables ipset iproute2 systemd ];

Discussion:
Describe the bug sshguard is not restarted when services.sshguard.services changes, instead the old configuration is used until sshguard is restarted through some non-nixos-rebuild means To Reproduce Steps to reproduce the behavior: services.sshguard with some value for services.sshguard.services services.sshguard.services -rebuild switch Expected behavior sshguard is restarted with the new services list passed to journalctl Screenshots n/a Additional context since the services list only affects the config file (not the systemd service) and the firewall backend does the same, this should also affect changes in the firewall backend. that probably doesn't matter though. 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 system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Change:
# Checks require an active X display. doCheck = false; <del> desktopItems = [ (makeDesktopItem { name = "rustdesk"; exec = meta.mainProgram; icon = "rustdesk"; desktopName = "RustDesk"; comment = meta.description; genericName = "Remote Desktop"; categories = ["Network"]; }) ]; </del> <ins> desktopItems = [ (makeDesktopItem { name = "rustdesk"; exec = meta.mainProgram; icon = "rustdesk"; desktopName = "RustDesk"; comment = meta.description; genericName = "Remote Desktop"; categories = [ "Network" ]; }) ]; postPatch = '' rm Cargo.lock ln -s ${./Cargo.lock} Cargo.lock ''; </ins> # Add static ui resources and libsciter to same folder as binary so that it # can find them.

Discussion:
Steps to reproduce the behavior: rustdesk None
Should be fixed in , thanks if you can test it.
tested and it works! Will close once it gets merged lands on unstable.
Change:
nativeCheckInputs = [ python3 <del> which </del> usbutils <ins> which </ins> ]; <ins> strictDeps = true; </ins> mesonFlags = [ "-Dgtk_doc=true" ];

Discussion:
Steps to reproduce the behavior: with enabled <!-- 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]:
This is not really a bug or a build failure, more of a feature request. The expression in nixpkgs doesn't set , as the build with it being set would fail. Someone needs to sit down and figure out why. I propose starting with the code of the two failed tests, seeing if something is missing from nativeCheckInputs. Happy to review a PR, but I don't have the bandwidth to drive this.
It's an indication that the packaging is incorrect. Incorrect packaging sounds like a packaging bug to me. See for the main tracking issue. If it's better categorised as a "bug" than a "build failure", then so be it, but it's absolutely not a "feature request." If you don't have time, that's a totally different topic, that could be just stated as is without the rest of it.
and the test for both use to get information about devices, which is not currently provided by any input. Adding (which provides ) to the check inputs makes this build without errors, even with . Since (a binary output) needs , should probably also be in the regular build inputs. (just stumbled across this randomly and thought I'd try to find out what's up)
Oh, very nice! Wondering how is currently sneaking in then :-) In any case, I'll try to add this to a PR and see how it goes!
I opened that does this, thanks!
The PR has been merged, this can be closed.
Change:
<ins> { corretto17 , fetchFromGitHub , gradle_7 , jdk17 , lib , stdenv , rsync , runCommand , testers }: let corretto = import ./mk-corretto.nix { inherit lib stdenv rsync runCommand testers; jdk = jdk17; gradle = gradle_7; version = "17.0.8.8.1"; src = fetchFromGitHub { owner = "corretto"; repo = "corretto-17"; rev = "9a3cc984f76cb5f90598bdb43215bad20e0f7319"; sha256 = "sha256-/VuB3ocD5VvDqCU7BoTG+fQ0aKvK1TejegRYmswInqQ="; }; }; in corretto </ins>

Discussion:
Project description <!-- Describe the project a little: --Amazon Coretto JDK Metadata homepage URL: source URL: license: GPL 2.0 platforms: linux (and all else if possible)