jiebi/CodeConvo huggingface dataset:
Change:
stdenv.mkDerivation rec { pname = "tracker-miners"; <del> version = "3.5.0"; </del> <ins> version = "3.5.2"; </ins> src = fetchurl { url = "mirror://gnome/sources/${pname}/${lib.versions.majorMinor version}/${pname}-${version}.tar.xz"; <del> sha256 = "F5ZmA9xDKphSa0kFhqSKzX+fWZNfeJXfxRcppGppAaM="; </del> <ins> sha256 = "QPuR+svZRo4m6+zHEdg2Mc2K6TkcYV1o27A8vKsbbGk="; </ins> }; <ins> patches = [ # Use cc.has_header_symbol to check for BTRFS_IOC_INO_LOOKUP # https://github.com/NixOS/nixpkgs/issues/228639 (fetchpatch { url = "https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/c08fbe0650d4a2ae915a21764f54c02eda9406d5.patch"; sha256 = "U81+yfg2sUkKl4tKMeB7pXJRNSeIE+2loT3/bvnhoKM="; }) ]; </ins> nativeBuildInputs = [ asciidoc docbook-xsl-nons

Discussion:
Package name: tracker-miners Latest released version: 3.5.1 Current version on the unstable channel: 3.5.0 <p</p- The package update itself is trivial, but I got stuck at addressing . There is now a ioctl check that runs: The program seems to build fine, but does not exit with 0: This makes the Btrfs subvolume feature disabled: I am not sure where to get start to enable this since in they decide this will be a hard check on next major bump (well, it should be possible to opt-out but it should be possible I guess). :seeno_evil: Note for maintainers: Please tag this issue in your PR.
I am getting , even though I do not use BTRFS so I assume this depends on the kernel version of the builder? (I am using .) That does not really sound like a good idea since users can use completely different kernel version than Hydra. Maybe it should be an and the check performed only when it is . Though I am not sure what the consequences are when incorrectly configured is used. Maybe it will need to be a runtime check instead?
I saved the program as a separate and compiled & ran with as root user and it exits with 1 for me as well. says I am on 6.3.0. I use btrfs so as root runs fine for me (if that matters). Hmmm then this is weird since it sounds like is introduced (is this the correct place to check such info?). But later I found in the BTRFS subvolumes feature is disabled as well :thinking: Edit: Looks like the fedora link is broken,
Apparently, it falls back to success since I do not use BTRFS: (both inside and outside the sandbox) <details<summaryModified <codetest.c</code</summary</detailsSo that does not really sound like a good test. Edit: I .
Hmmm now I wonder if their original idea is to check whether the code , probably knowing is there is already enough? (I assume they are not supporting < 2.6.34 kernels then I expect all linux should have it?) It looks like they already has some .
Could you try running the modified in build sandbox to find out why specifically it fails for you?
This is using and putting in : This is not in builder sandbox and run as root:
The fix is now merged upstream:
Change:
<ins> { lib , buildNpmPackage , fetchFromGitHub , makeWrapper , ffmpeg , yt-dlp , makeDesktopItem , electron }: buildNpmPackage rec { pname = "ytDownloader"; version = "3.17.3"; src = fetchFromGitHub { owner = "aandrew-me"; repo = "ytDownloader"; rev = "refs/tags/v${version}"; hash = "sha256-aqQGOqPLKKTBjWjL3KyRD4paBGCQLhCBjXwVVhoHDSk="; }; npmDepsHash = "sha256-lhFyiWy9dgnxxaElavzqA4YpRm7cVC23pvL5Kwve58E="; nativeBuildInputs = [ makeWrapper ]; buildInputs = [ ffmpeg yt-dlp ]; desktopItem = makeDesktopItem { name = "YTDownloader"; exec = "ytdownloader %U"; icon = "ytdownloader"; desktopName = "YT Downloader"; comment = "A modern GUI video and audio downloader"; categories = [ "Utility" ]; startupWMClass = "YTDownloader"; }; ELECTRON_SKIP_BINARY_DOWNLOAD = "1"; dontNpmBuild = true; # Replace hardcoded ffmpeg and ytdlp paths # Also stop it from downloading ytdlp postPatch = '' substituteInPlace src/renderer.js  --replace-fail ${__dirname}/../ffmpeg '${lib.getExe ffmpeg}'  --replace-fail 'path.join(os.homedir(), ".ytDownloader", "ytdlp")' '`${lib.getExe yt-dlp}`'  --replace-fail '!!localStorage.getItem("fullYtdlpBinPresent")' 'true' ''; postInstall = '' makeWrapper ${electron}/bin/electron $out/bin/ytdownloader  --add-flags $out/lib/node_modules/ytdownloader/main.js install -Dm444 assets/images/icon.png $out/share/pixmaps/ytdownloader.png install -Dm444 "${desktopItem}/share/applications/"* -t $out/share/applications ''; meta = { description = "A modern GUI video and audio downloader"; homepage = "https://github.com/aandrew-me/ytDownloader"; license = lib.licenses.gpl3Only; maintainers = with lib.maintainers; [ chewblacka ]; platforms = lib.platforms.all; mainProgram = "ytdownloader"; }; } </ins>

Discussion:
Project description A modern GUI video and audio downloader supporting (using yt-dlp) Metadata homepage URL: source URL: license: GPL-3.0 platforms: (any?) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks!
Change:
theme-vertex = callPackage ../data/themes/vertex { }; <ins> tibetan-machine = callPackage ../data/fonts/tibetan-machine { }; </ins> times-newer-roman = callPackage ../data/fonts/times-newer-roman { }; tipa = callPackage ../data/fonts/tipa { };

Discussion:
Project description Add Tibetan Machine OpenType font for Tibetan, Dzongkha, and Ladakhi languages. Metadata homepage URL: source URL: mirror://debian/pool/main/f/fonts-tibetan-machine/fonts-tibetan- license: gpl2+ platforms: all
Change:
<del> { lib, stdenv, fetchurl, makeWrapper, jre }: </del> <ins> { lib, stdenv, fetchurl, makeWrapper, jre, zip }: </ins> stdenv.mkDerivation rec { version = "13.8.0";

Discussion:
mediathekview might be affected, the latest version 13.8.1 patched the distributed log4j version As it also updated compatibility to Java 17, and no working Java 17 distribution is in 21.11 or master atm, I'm still working on how to best address this.
See PR Full update depends on updated Java 17 , manual patching might be needed in the mean time. As it is distributed as a binary and log4j is packed into the main jar, I'm a bit stumped at the moment how to approach this.
Might work
See PR for a fix
Change:
./services/networking/icecream/daemon.nix ./services/networking/icecream/scheduler.nix ./services/networking/imaginary.nix <ins> ./services/networking/inadyn.nix </ins> ./services/networking/inspircd.nix ./services/networking/iodine.nix ./services/networking/iperf3.nix

Discussion:
ddclient was removed in , with inadyn being the closest suggested replacement. inadyn is packaged in Nixpkgs, but does not have a NixOS module. An inadyn NixOS module would be useful as a replacement.
The first step is fixing inadyn itself, since it currently won't start due to a wrongly configured , see .
We will also need to decide if it's better to run as a systemd service, timer, or give the user the option to choose. I lean towards timer.
AFAICS inadyn does not contain additional logic to detect IP address changes. Because of this I would also lean towards the timer functionality.
I think it does. Looking at , inadyn will only update the ip if changed every seconds and always update it every seconds. I'm not clear on how those options behave in oneshot mode.
Well, so far I called ddclient with cron, since the machine running will not easil see altered public IP change. I tried to use inadyn but can't get it to work with /
I've had some time to poke around this a bit more, and it seems like inadyn cannot read credentials from the environment or a file separate to the config, so all your DDNS credentials will end up world-readable in the store.
I've made a pretty barebones module for my personal config here It runs inadyn in oneshot mode using a timer, and is configured entirely by specufying a .
Submitted a full NixOS module as , I would appreciate if inadyn users could test it :slightlysmilingface:.
Add a small example for how to use it?
Sure, here's a config to use namecheap:
Change:
else if versionAtLeast config.system.stateVersion "16.03" then pkgs.postgresql_9_5 else throw "postgresql_9_4 was removed, please upgrade your postgresql version."); <del> services.postgresql.dataDir = mkDefault (if versionAtLeast config.system.stateVersion "17.09" then "/var/lib/postgresql/${cfg.package.psqlSchema}" else "/var/db/postgresql"); </del> <ins> services.postgresql.dataDir = mkDefault "/var/lib/postgresql/${cfg.package.psqlSchema}"; </ins> services.postgresql.authentication = mkAfter ''

Discussion:
Describe the bug A clear and concise description of what the bug is. I have The error I got when starting the service is:
The folder is owned by user postgres:
what are the permissions on ?
it's
it works if I set it to but is created by the build/installation. why doesn't it set the right permission?
Looks line should be a one time required step and you're good to go :+1: Looks like with both and together pushes permissions up to all new parent directories. The module is still using (which is deprecated) so the module should be updated to remove that and fix your issue at the same time. Thanks for reporting!
Thank you for your help!
Change:
passthru.updateScript = nix-update-script { }; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "Cool new OpenPGP implementation"; homepage = "https://sequoia-pgp.org/"; changelog = "https://gitlab.com/sequoia-pgp/sequoia-sq/-/blob/v${version}/NEWS"; <del> license = licenses.gpl2Plus; maintainers = with maintainers; [ minijackson doronbehar ]; </del> <ins> license = lib.licenses.gpl2Plus; maintainers = with lib.maintainers; [ minijackson doronbehar ]; </ins> mainProgram = "sq"; }; }

Discussion:
Steps to reproduce the behavior: Observed: Full checkPhase log (copied from Garnix): 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. --- system: host os: multi-user?: sandbox: version: nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The checkPhase still fails with this PR applied, but it is a different error: Error: While creating /homeless- Caused by: Permission denied (os error 13)
Thanks for the report (I thought I rebuilt it successfully before I opened the PR). Now should be ready now (the failing test is skipped, and an upstream issue was created).
Change:
libstartup_notification libXtst libXdamage <ins> mesa </ins> muffin networkmanager polkit <ins> pythonEnv </ins> libxml2 libgnomekbd gst_all_1.gstreamer

Discussion:
I have 2 clear bugs for cinnamon that I can't find a way to solve 1- not working due to missing of 2- doesn't show events due to missing of both of the issues related to Steps to reproduce the behavior: in any of the bugged apps
Change:
<ins> { lib, stdenvNoCC, fetchFromGitHub, unstableGitUpdater, lua, }: stdenvNoCC.mkDerivation { pname = "librime-lua"; version = "0-unstable-2024-05-19"; src = fetchFromGitHub { owner = "hchunhui"; repo = "librime-lua"; rev = "7be6974b6d81c116bba39f6707dc640f6636fa4e"; hash = "sha256-jsrnAFE99d0U0LdddTL7G1p416qJfSNR935TZFH3Swk="; }; propagatedBuildInputs = [ lua ]; installPhase = '' runHook preInstall mkdir $out cp --archive --verbose src/ $out install --mode=644 --verbose --target-directory=$out CMakeLists.txt  LICENSE  README.md runHook postInstall ''; passthru.updateScript = unstableGitUpdater { hardcodeZeroVersion = true; }; meta = { description = "Extending RIME with Lua scripts"; homepage = "https://github.com/hchunhui/librime-lua"; license = lib.licenses.bsd3; maintainers = with lib.maintainers; [ linj xddxdd ]; }; } </ins>

Discussion:
Project description as a substitute of librime, librime-lua add lua engine to librime, so we can extend rime by lua. Many schemas of rime use librime-lua but not rime. So please add librime-lua. Metadata homepage URL: source URL: license: bsd3 platforms: linux
I do not think we have in Nixpkgs. Let's reopen this.
Change:
buildPythonPackage rec { pname = "indexed_gzip"; version = "1.8.7"; <del> format = "setuptools"; </del> <ins> pyproject = true; </ins> disabled = pythonOlder "3.7";

Discussion:
Steps to reproduce the behavior: python3Packages.ratarmountcore This first occurs after updates to and itself. The failure is not actually in a test, and occurs after the tests run. This indicates that some difference in the way the derivation is executing tests compared to upstream's CI is causing the error. Please run and paste the result. Not relevant; the log is on Hydra. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems that only the rapidgzip backend got updated but not ratarmountcore. Either downgrade rapidgzip or update ratarmountcore to 0.6.3 if possible. I'll have to see to get the latter update merged, it seems the auto-update bot does not work for ratarmountcore. This should fix the and output. I have no idea about the last 2 error lines. I cannot reproduce it with nix 2.16.1 on Ubuntu. The command runs fine:
Change:
<del> { lib, buildPythonPackage, fetchFromGitHub, fetchpatch </del> <ins> { lib, buildPythonPackage, fetchFromGitHub </ins> , acme, aiohttp, snitun, attrs, pycognito, warrant <del> , pytest-aiohttp, asynctest, atomicwrites, pytest, pythonOlder }: </del> <ins> , pytest-aiohttp, asynctest, atomicwrites, pytest }: </ins> buildPythonPackage rec { pname = "hass-nabucasa"; <del> version = "0.37.2"; </del> <ins> version = "0.39.0"; </ins> src = fetchFromGitHub { owner = "nabucasa"; repo = pname; rev = version; <del> sha256 = "0gv8p9nba7269qhc05ds0i79wz4419qjfhn7k9kcngfj1yngb6dm"; </del> <ins> sha256 = "1bsvwxddpp4dsq3k2320qrx5x9lscqzffzz1zj6fbwgc4741f01w"; </ins> }; postPatch = ''

Discussion:
Describe the bug To Reproduce Steps to reproduce the behavior: Additional context Add any other context about the problem here. 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(wmertens): channels(root): nixpkgs: (nixos-unstable channel)
Fixed by
Change:
libversion = callPackage ../development/libraries/libversion { }; <del> libvirt = callPackage ../development/libraries/libvirt { }; </del> <ins> libvirt = callPackage ../development/libraries/libvirt { inherit (darwin.apple_sdk.frameworks) Carbon AppKit; }; </ins> libvirt_5_9_0 = callPackage ../development/libraries/libvirt/5.9.0.nix { }; libvirt-glib = callPackage ../development/libraries/libvirt-glib { };

Discussion:
Found in It does build on and . Refs ZHF <!-- 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. Maintainer information:
Is there a general fix for the error? I'm seeing this with (this issue was the only one in nixpkgs that matched that string, sorry if I'm completely off base, I just have no idea where to go on this)
Change:
<ins> --- xf86-video-dummy-0.3.6/src/dummy_driver.c	2014-11-05 19:24:02.668656601 +0700 +++ xf86-video-dummy-0.3.6.new/src/dummy_driver.c	2014-11-05 19:37:53.076061853 +0700 @@ -55,6 +55,9 @@ #include <X11/extensions/xf86dgaproto.h> #endif +/* Needed for fixing pointer limits on resize */ +#include "inputstr.h" + /* Mandatory functions */ static const OptionInfoRec *	DUMMYAvailableOptions(int chipid, int busid); static void     DUMMYIdentify(int flags); @@ -713,6 +716,26 @@ RRTellChanged(pScrn->pScreen); } #endif +    //ensure the screen dimensions are also updated: +    pScrn->pScreen->width = mode->HDisplay; +    pScrn->pScreen->height = mode->VDisplay; +    pScrn->virtualX = mode->HDisplay; +    pScrn->virtualY = mode->VDisplay; +    pScrn->frameX1 = mode->HDisplay; +    pScrn->frameY1 = mode->VDisplay; + +    //ensure the pointer uses the new limits too: +    DeviceIntPtr pDev; +    SpritePtr pSprite; +    for (pDev = inputInfo.devices; pDev; pDev = pDev->next) { +        if (pDev->spriteInfo!=NULL && pDev->spriteInfo->sprite!=NULL) { +            pSprite = pDev->spriteInfo->sprite; +            pSprite->hotLimits.x2 = mode->HDisplay; +            pSprite->hotLimits.y2 = mode->VDisplay; +            pSprite->physLimits.x2 = mode->HDisplay; +            pSprite->physLimits.y2 = mode->VDisplay; +        } +    } return TRUE; } </ins>

Discussion:
Describe the bug Attempting to start xpra fails with the following X server log: To Reproduce Steps to reproduce the behavior: run start :200
Change:
containers-reloadable = handleTest ./containers-reloadable.nix {}; containers-restart_networking = handleTest ./containers-restart_networking.nix {}; containers-tmpfs = handleTest ./containers-tmpfs.nix {}; <ins> containers-unified-hierarchy = handleTest ./containers-unified-hierarchy.nix {}; </ins> convos = handleTest ./convos.nix {}; corerad = handleTest ./corerad.nix {}; coturn = handleTest ./coturn.nix {};

Discussion:
Containers spawned by nixos-container fall back to old cgroup hierarchy, which does not support proper delegation of resource limits to processes running in that container. Steps to reproduce the behavior: will show Tainted: cgroupsv1 will show a mount This will be allowed to consume all memory of the machine until it runs out, the 4G cap is not enforced I expected the container to use a unified cgroup hierarchy, same as on the host, with full delegation and control over its subtree.
This is the log from , using declarative containers: I thought it could be relevant, but after googling around, these seem like errors that happen after systemd decided to use cgroupv1. I'm not sure how to debug its decision to use legacy cgroups inthe first place.
According to , systemd-nspawn tries to detect the systemd-version used in the container by locating a shared library with the version of systemd in the name. you can see the paths searched. The lookup fails on nix-based containers and systemd-nspawn falls back to legacy cgroups. You can test this yourself by symlinking from your Nix store to in your container. After restarting, reports .
Thanks, that was it. I also noticed this in the code But the following is not enough to enable it: Running didn't help either, so I'm not sure how you're supposed to use it. Should we add a symlink as a workaround? I think it'd make sense to fix it for all users of nixos-containers by defining it somewhere around here:
According to , This is not what we want. The environment variable is a good find though. I'm not sure why did not work for you, but adding to the following line worked. Can you reproduce this fix? PS: A PR fixing this issue would ideally include a regression test (almost like ) checking if the container runs with .
That worked! I can see with that the container is no longer tainted. Working on a PR now
Change:
''} } <del> siteAutoloads="$out/share/emacs/site-lisp/nix-generated-autoload.el" touch $siteAutoloads </del> # Iterate over the array of inputs (avoiding nix's own interpolation) for pkg in "''${requires[@]}"; do linkEmacsPackage $pkg <del> find $pkg -name "*-autoloads.el"  -exec echo (load "{}" 'noerror 'nomessage) ; >> $siteAutoloads </del> done <del> echo "(provide 'nix-generated-autoload)" >> $siteAutoloads </del> siteStart="$out/share/emacs/site-lisp/site-start.el" siteStartByteCompiled="$siteStart"c

Discussion:
The file generated by the Emacs wrapper is redundant because the autoload definitions are already processed by the builtin : the is loaded after with the command line option , but loads the package autoloads before . We can understand this better by considering a few scenarios. If we start Emacs with disabled, then the autoloads will not be available in because is not loaded until later: If we modify the wrapper as in so that is not loaded, the autoloads will still be found as long as is enabled: is enough on its own to handle autoloads for the Emacs wrapper. Therefore, I propose to remove in favor of the builtin Emacs functionality.
Somehow, removing this broke from emacs-overlay. I have to manually run or anything depending on autoloaded tramp functions errors out with "no such function". I do disable as my site-lisp directory is managed by Nix. Is this configuration no longer recommended/supported? Is there a way to just engage 's autoload mechanism without allowing it to access the network or install packages?
I also fully disable since all of my emacs packages are installed via nix and noticed this change broke things for me. I'm interested in this as well. Edit: Maybe this:
Change:
open = lib.mkOption { example = true; description = "Whether to enable the open source NVIDIA kernel module."; <del> type = lib.types.bool; </del> <ins> type = lib.types.nullOr lib.types.bool; default = if lib.versionOlder nvidia_x11.version "560" then false else null; </ins> defaultText = lib.literalExpression '' <del> lib.mkIf (lib.versionOlder config.hardware.nvidia.package.version "560") false </del> <ins> if lib.versionOlder config.hardware.nvidia.package.version "560" then false else null </ins> ''; }; gsp.enable = lib.mkEnableOption '' the GPU System Processor (GSP) on the video card '' // { <ins> default = useOpenModules || lib.versionAtLeast nvidia_x11.version "555"; </ins> defaultText = lib.literalExpression '' <del> config.hardware.nvidia.open || lib.versionAtLeast config.hardware.nvidia.package.version "555" </del> <ins> config.hardware.nvidia.open == true || lib.versionAtLeast config.hardware.nvidia.package.version "555" </ins> ''; }; };

Discussion:
Steps to reproduce the behavior: after update 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. But I am using flakes and following unstable. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It was an intentional breaking change
TY.
To sum up, is non-optional and must be set now: When , use open source NVIDIA kernel module, this is now recommended by NVIDIA, but it doesn't work with older drivers. When , use proprietary kernel module. This is needed for people with older NVIDIA cards. More information:
Change:
io = callPackage ../development/interpreters/io { }; <del> j = callPackage ../development/interpreters/j {}; </del> <ins> j = callPackage ../development/interpreters/j { stdenv = clangStdenv; }; </ins> janet = callPackage ../development/interpreters/janet {};

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: j <!-- 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: 901 release-f desired version: 902 release-b <!-- 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:
sed -i '/-ffloat-store/d' cmake/pcl_find_sse.cmake ''; <del> nativeBuildInputs = [ pkg-config cmake wrapQtAppsHook ]; </del> <ins> nativeBuildInputs = [ pkg-config cmake wrapQtAppsHook ] ++ lib.optionals withCuda [ cudaPackages.cuda_nvcc ]; </ins> buildInputs = [ eigen libusb1

Discussion:
Steps to reproduce the behavior: with the following flake: I think this broke with the recent cudaPackages changes, but I haven't figured out the responsible commit. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Not directly relevant but we should rename -for consistency at some point.