jiebi/CodeConvo huggingface dataset:
Change:
in stdenv.mkDerivation { inherit pname version src; <del> buildInputs = [ swiProlog ]; </del> <ins> buildInputs = [ swi-prolog ]; </ins> nativeBuildInputs = [ which makeWrapper ]; makeFlags = [

Discussion:
It seems that errors with when attempting to have in . There has been no updates in the lspserver. I came across this while trying to update my systems. Currently, says , so that was the last build I had with the lsp not causing a build failure. Steps to reproduce the behavior: this expression: It seems this started happening in . Works fine on the parent commit. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems adding to allows it to build, it is not clear to me how is being used here as I am not familiar with how packs work in swiProlog and why made this necessary. From looking at that commit in , it appears to be something that changed upstream. This builds:
I can confirm that with 9.1.21, swi-prolog + lsp-server builds just fine, even with the latest packaging. Something must indeed have changed upstream. 9.1.22 is the first version that stops building for me. The notes that the pack system got a refactor at that point, so that's probably what is going on here, but nothing indicates a sudden need for git. If git is now necessary for pack installation (even if we already pre-cloned everything) it should be a dependency. any idea why git became necessary here?
We can resolve this with a patch to SWI-Prolog to respect in the options, then adding that option to our invocation. I submitted a PR to SWI-Prolog (SWI-Prolog/swipl-devel). If upstream merges this, we can just apply the same patch to stable.
swi-prolog 9.2.7 backported the PR mentioned above. I've modified the package definition to supply the proper flag which suppresses git use during extraPacks install.
Change:
{ lib , buildPythonPackage , fetchFromGitHub <ins> , flit-core </ins> , freezegun <del> , hatchling </del> , pytest , pytestCheckHook , pythonOlder

Discussion:
Failure happens locally as well when trying to build spotdl on the nixos-23.05 branch. this the tail of the log: The last line is apparently unrelated: (maintainer) (recent bumps)
This test doesn't fail if spotdl is built using version from this nixpkgs commit , I'm not sure if this is an upstream issue with spotdl while using newer yt-dlp versions (newer than ).
Change:
]; services.nginx.enable = true; services.nginx.package = pkgs.nginx-lua; <del> services.nginx.enableSandbox = true; </del> services.nginx.virtualHosts.localhost = { extraConfig = '' location /test1-write {

Discussion:
ping It was agreed that should be removed before . It was generally accepted that an option isn't a great idea and was to the module temporarily for ease of testing. It is important to remove this because other people have seen this option and started believing this is an accepted design pattern for NixOS modules - we don't want people getting the wrong idea and having more options like this slip in. can you please file a PR removing this option and the entry from the release notes?
Change:
<ins> { lib , stdenv , fetchFromGitHub , pkg-config , cmake , qtbase , qttools , spdlog , ffmpeg , taglib , wrapQtAppsHook , makeDesktopItem , copyDesktopItems }: stdenv.mkDerivation rec { pname = "easyaudiosync"; version = "1.1.1"; src = fetchFromGitHub { owner = "complexlogic"; repo = "EasyAudioSync"; rev = "v${version}"; hash = "sha256-w98tj9BuixPhuDgwn74EYY0gvKH6kbfQmtg030RWRU0="; }; patches = [ ./0001-fix-project-name.patch ./0002-fix-qt67-deprecated-methods.patch ./0003-fix-darwin-app.patch ./0004-force-qt6.patch ]; nativeBuildInputs = [ cmake pkg-config wrapQtAppsHook ] ++ lib.optional stdenv.isLinux copyDesktopItems; buildInputs = [ qtbase qttools ffmpeg spdlog taglib ]; installPhase = '' runHook preInstall '' + lib.optionalString stdenv.isDarwin '' mkdir -p $out/Applications mv "easyaudiosync.app" "Easy Audio Sync.app" cp -r "Easy Audio Sync.app" $out/Applications '' + lib.optionalString stdenv.isLinux '' install -Dm755 easyaudiosync $out/bin/easyaudiosync for RES in 48 64 128 256; do install -Dm755 "$src/assets/icons/easyaudiosync''${RES}.png" "$out/share/icons/hicolor/''${RES}x''${RES}/apps/easyaudiosync.png" done install -Dm755 "$src/assets/icons/easyaudiosync.svg" "$out/share/icons/hicolor/scalable/apps/easyaudiosync.svg" '' + '' runHook postInstall ''; desktopItems = [ (makeDesktopItem { name = "easyaudiosync"; exec = "easyaudiosync"; icon = "easyaudiosync"; desktopName = "Easy Audio Sync"; categories = [ "Qt" "Audio" "AudioVideo" ]; comment = "Audio library syncing and conversion utility"; }) ]; meta = with lib; { description = "Audio library syncing and conversion utility"; longDescription = '' Easy Audio Sync is an audio library syncing and conversion utility. The intended use is syncing an audio library with many lossless files to a mobile device with limited storage. The program's design is inspired by the rsync utility. It supports folder-based source to destination syncing, with added audio transcoding capability, and is GUI-based instead of CLI-based. ''; homepage = "https://github.com/complexlogic/EasyAudioSync"; license = licenses.unlicense; maintainers = with maintainers; [ matteopacini ]; platforms = platforms.linux ++ platforms.darwin; }; } </ins>

Discussion:
Project description From the project GitHub: Easy Audio Sync is an audio library syncing and conversion utility. The intended use is syncing an audio library with many lossless files to a mobile device with limited storage. The program's design is inspired by the utility. It supports folder-based source to destination syncing, with audio transcoding capability, and is GUI-based instead of CLI-based. Metadata homepage URL: source URL: license: Public Domain (Unlicense) platforms: Linux, Windows, and macOS Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
''; license = licenses.gpl2Plus; <del> platforms = platforms.linux; </del> <ins> platforms = platforms.unix; </ins> maintainers = teams.gnome.members ++ teams.pantheon.members; }; }

Discussion:
Project description homebrew provides an evince installation method on macos: . Is this possible for nix? homepage URL: source URL: license: gpl2+ platforms: darwin
Are you interested in this?
Not sure if I'm the right person to tag. Don't think I've ever been involved in anything related
Seems to build fine at least, just needs to have expanded to . !
thanks very much :)
Change:
grobi = callPackage ../tools/X11/grobi { }; <ins> gscan2pdf = callPackage ../applications/graphics/gscan2pdf { }; </ins> gti = callPackage ../tools/misc/gti { }; hdate = callPackage ../applications/misc/hdate { };

Discussion:
I'm going to be putting this aside for a bit but it still needs some work, so I'm posting this here till I have a PR ready. At the moment this appears to generate a functional gscan2pdf derivation, however I would like to find a way to allow at least part, if not all of the (graphical) tests to be run. I also intend to merge the perl packages into perl packages properly instead of leaving them like this, and I need to look into whether they have any extra things I should configure, currently this is somewhat modified output of nix-generate-from-cpan. Also I don't know if this should go into tools/graphics, or into perlPackages, or what. Though I'm leaning towards the former. Also please send suggestions on how to improve the script in general. If anyone wants to pick this up, please do.
Any progress on this?
Change:
, hyphen , unrarSupport ? false , chmlib <del> , pythonPackages </del> <ins> , python3Packages </ins> , libusb1 , libmtp , xdg_utils

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: calibre <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 4.23.0 desired version: 5.6 <!-- 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:
example = "/home/foo"; description = '' The home directory that the ollama service is started in. <ins> See also `services.ollama.writablePaths` and `services.ollama.sandbox`. </ins> ''; }; models = lib.mkOption {

Discussion:
Steps to reproduce the behavior: ollama service the model dir Ollama should work, files and directories have rw permissions for anyone and the file system is not read-only. It used to work before an update. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Could you try manually renaming the file to see if you get the same error? If you still get the error, the problem is probably with your system config. If you don't get the error, the problem could be with the ollama binary, or with the service config. Maybe try it as root as well to see if there's a difference. By the way, the reason it's trying to rename the files is due to a change in .
Renaming files solves the problem of starting ollama, but does not solve the overall problem. I can't install a new model, for example.
I found what the problem is. The ollama service has set, which creates a new user for the service and enables some sandboxing that includes making most of the filesystem read-only. I'm not sure at the moment the best way to fix this without compromising on security, so I'll do some more research on how systemd works, and any relevant systemd options. At worst, I should be able to create a nixos option that disables this sandboxing entirely. If you have any suggestions, I'd be happy to hear them.
In the meantime, a temporary workaround that I think should work is this nixos config:
Change:
# we accept this fact because xcode_locator is only a short-lived process used during the build. ./no-arc.patch <ins> ./gcc11.patch </ins> # --experimental_strict_action_env (which may one day become the default # see bazelbuild/bazel#2574) hardcodes the default # action environment to a non hermetic value (e.g. "/usr/local/bin").

Discussion:
(3.7) on master for a few days now, even reached nixpkgs-unstable. I'm running into this because it's a dependency for tensorflow-probabilty. It's probably needs some cxx standard flag -
Change:
ristretto xfce4-appfinder xfce4-notifyd <del> xfce4-screensaver </del> xfce4-screenshooter xfce4-session xfce4-settings

Discussion:
introduced a locker by consequence if you enable the XFCE4 DE and the new locker replaces any other already defined without a trivial way to disable. Steps to reproduce the behavior: any other locker using something like 4 locker is used anyway A way to enable XFCE4 stuff but without the locker, it can be enabled by default but with a option to disable. (I can't screenshot on the lockscreen) This is the current commit of my config: <!-- 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:
}: with lib; <ins> let python = python3Packages.python; optix = fetchzip { url = "https://developer.download.nvidia.com/redist/optix/v7.0/OptiX-7.0.0-include.zip"; sha256 = "1b3ccd3197anya2bj3psxdrvrpfgiwva5zfv2xmyrl73nb2dvfr7"; }; </ins> <del> let python = python3Packages.python; in </del> <ins> in </ins> stdenv.mkDerivation rec { pname = "blender"; version = "2.91.0";

Discussion:
Feature request As the title says, enable OptiX in Blender. I considered adding OptiX as a package request, but it seems like Nvidia wants to be the only one to distribute that package. How Arch linux has implemented it I looked at the PKGBUILD of Blender for arch, and they package OptiX with the blender package. How the Blender documentation suggests implementing it page describes what needs to be done to activate OptiX in the build process. To summarize: Install OptiX SDK 7.0, and add the following build flags I could try implementing this myself, but I don't know if I'll succeed, since I'm very new to NixOS. Would submitting a pull request where I've done my what I can be any helpful? Notify maintainers
I'm currently using this overlay, which seems to work: I won't have much time during the next two days, but after that if no one else has done it already I'm happy to make a PR. In the meantime, using the above overlay should work if you need OptiX support right now.
I have created a pull request, to the best of my abilities:
Change:
bonzomatic = callPackage ../applications/editors/bonzomatic { }; <del> bottles = callPackage ../applications/misc/bottles { wine = null; }; </del> <ins> bottles = callPackage ../applications/misc/bottles/fhsenv.nix { }; bottles-unwrapped = callPackage ../applications/misc/bottles { }; </ins> brave = callPackage ../applications/networking/browsers/brave { };

Discussion:
error when creating a bottle Steps to reproduce the behavior: bottles to create a new bottle during dxvk installation process with the following error message No error when trying to create a bottle ! I'm pretty new to nixos so it might be a configuration error on my part I apologize in advanced if I tagged the wrong maintainers
It should be fixed in (I don't reproduce it there). (I think it's caused by the fact I )
gotcha. feel free to close if you think it's gonna be fixed in next release. thanks :)
Change:
<ins> { lib , stdenv , fetchFromGitHub , jq , curl , glow , makeWrapper }: let pname = "chatgpt-shell-cli"; # no tags version = "master"; in stdenv.mkDerivation { inherit pname version; src = fetchFromGitHub { owner = "0xacx"; repo = "chatgpt-shell-cli"; rev = version; hash = "sha256-hYLrUya4UCsIB1J/n+jp1jFRCEqnGFJOr3ATxm0zwdY="; }; nativeBuildInputs = [ makeWrapper ]; installPhase = '' runHook preInstall mkdir -p $out/bin install -Dm755 chatgpt.sh -t $out/bin runHook postInstall ''; postInstall = '' wrapProgram $out/bin/chatgpt.sh  --prefix PATH : ${lib.makeBinPath [ jq curl glow ]} ''; meta = with lib; { homepage = "https://github.com/0xacx/chatGPT-shell-cli"; description = "Simple shell script to use OpenAI's ChatGPT and DALL-E from the terminal. No Python or JS required."; license = licenses.mit; maintainers = with maintainers; [ jfvillablanca ]; }; } </ins>

Discussion:
Project description A simple, lightweight shell script to use OpenAI's chatGPT and DALL-E from the terminal without installing python or Metadata homepage URL: URL: mit platforms: unix, linux, darwin, ...
A can be got from
Change:
{ lib , stdenv , fetchFromGitHub <ins> , fetchpatch </ins> , cmake , gtest , pkg-config

Discussion:
Project description ONNX Runtime: cross-platform, high performance ML inferencing and training accelerator . Onnxruntime is already packaged. I would like to have the version with gpu support to be able to package obs-backgroundremoval with gpu support (). Related: Metadata homepage URL: source URL: license: mit platforms: linux
Obs-backgroundremoval includes tensorrtproviderfactory.h to build
need it, too
Is it possible to add gpu support to the obs-backgroundremoval as this issue is closed?
It may be possible. If anyone wants to open a PR for that, please base it on the current update PR
Change:
]); RENPY_DEPS_INSTALL = lib.concatStringsSep "::" (map (path: path) [ <del> SDL2 SDL2.dev libpng ffmpeg.out freetype glew.dev libGLU libGL fribidi zlib </del> <ins> SDL2 SDL2.dev libpng ffmpeg.lib freetype glew.dev libGLU libGL fribidi zlib </ins> ]); enableParallelBuilding = true;

Discussion:
Steps to reproduce the behavior: spotify It was building with a few commits behind, but there were no updates to the package, so I'm not sure why it fails now. Please run and paste the result.
Change:
inherit (args) src; inherit (go) GOOS GOARCH; <ins> prePatch = args.prePatch or ""; </ins> patches = args.patches or []; patchFlags = args.patchFlags or []; <ins> postPatch = args.postPatch or ""; </ins> preBuild = args.preBuild or ""; <ins> postBuild = args.postBuild or ""; </ins> sourceRoot = args.sourceRoot or ""; GO111MODULE = "on";

Discussion:
I keep hitting a heisenbug in , where we get . this is triggered because, per suggestion, we split setup into and . this makes intuitive sense, because the former is a bunch of nix related in place substitutions, and the latter is a pre-build code generation phase. because this suggestion came late in the development process, I had already seeded a fod into the nix store, with a single containing all the logic. as such, when I broke them apart, the derivation was broken, but it worked on my system. this caused a large amount of delay, and probably annoyed sorry. I understand the logic of wanting to share between the main derivation and , but most authors will not be clear that only gets shared, and it needs to work without other hooks. Steps to reproduce the behavior: a derivation with both attrs build the derivation in two (say and ) such that alone is not enough that it builds successfully locally that it fails to build on empty nix store I would have expected that we pass all the hooks or none. I know we already have , and maybe that is the correct way to pass things like or , e.g. and respectively. the ux for this would not be too bad: , but I get that this is a breaking change. Please run and paste the result.
I've seen a couple of people get bitten by this sort of thing, been meaning to do something about. Give me a week or two and I'll take a look at improving it.
yep, no rush. I opened the issue half to document what went wrong, so that other people searching this might find it. I am also happy to help, if you can sketch out what your proposed solution would be, e.g. my naive suggestion.
Change:
'' + lib.optionalString (stdenv.hostPlatform.isAarch32 && stdenv.hostPlatform.isMusl) '' ln -s src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h src/syscfg/lock-obj-pub.arm-unknown-linux-musleabihf.h ln -s src/syscfg/lock-obj-pub.arm-unknown-linux-gnueabi.h src/syscfg/lock-obj-pub.linux-musleabihf.h <ins> '' # This file was accidentally excluded from the sdist until # 013720333c6ec1d38791689bc49ba039d98e16b3, post release. # TODO make unconditional next mass rebuild + lib.optionalString (stdenv.buildPlatform != stdenv.hostPlatform) '' cp ${fetchurl { url = "https://raw.githubusercontent.com/gpg/libgpg-error/50e62b36ea01ed25d12c443088b85d4f41a2b3e1/src/gen-lock-obj.sh"; sha256 = "10cslipa6npalj869asaamj0w941dhmx0yjafpyyh69ypsg2m2c3"; }} ./src/gen-lock-obj.sh chmod +x ./src/gen-lock-obj.sh </ins> ''; outputs = [ "out" "dev" "info" ];

Discussion:
Somewhere between the current channel and cross-compilation broke. It's a dependency of gpg, and systemd is usually compiled with a minimal gpg, to verify container image signatures - meaning this currently breaks NixOS cross. It's probably in the dependency closure of a lot of other stuff, so fixing it is probably better than building a systemd without a minimal gpg ;-) seems unrelated - while it looks like this might have , it was targeted to , is currently in , but not yet in master - so it broke before that, and still fails with it. I'm currently bisecting this, but wanted to open a tracking issue, in case anyone else is running into this. cc
This has briefly been discussed in yesterday: ;
I'd be not so sure that it wasn't . Reverting on top of makes buildable for me. According to they had cross fixes in both and .
Hmm, my bisecting didn't get me too far: I ed all other build failures that weren't exactly the one as found here. did you get any further?
no skips in my log but ive hit a stdenv rebuild, and need to head to bed
Yeah bisecting stuff that went to staging is a PITA. Especially if it's cross stuff. I recognised that is part of your list of possible commits. I'm pretty sure this is an upstream problem.
There are some fixes upstream since the release, trying them.
bisect confirms that the problem did happen at a recent version update
So work took me away from this, but the main problem might be that the script that generates the header during include was not in extra dist. There was a commit fixing this, but of course doesn't regenerate the tarball. Just fetching that file and seeing if any of the is actually needed is the next thing I'm going to try.
Change:
<ins> { stdenv, fetchurl, gfortran, arpack, spooles, openblas }: stdenv.mkDerivation rec { pname = "calculix"; version = "2.15"; src = fetchurl { url = "http://www.dhondt.de/ccx_${version}.src.tar.bz2"; sha256 = "0d4axfxgm3ag4p2vx9rjcky7c122k99a2nhv1jv53brm35rblzdw"; }; nativeBuildInputs = [ gfortran ]; buildInputs = [ arpack spooles openblas ]; NIX_CFLAGS_COMPILE = [ "-I${spooles}/include/spooles" ]; patches = [ ./calculix.patch ]; postPatch = '' cd ccx*/src ''; installPhase = '' install -Dm0755 ccx_${version} $out/bin/ccx ''; meta = with stdenv.lib; { homepage = "http://www.calculix.de/"; description = "Three-dimensional structural finite element program"; license = licenses.gpl2Plus; maintainers = with maintainers; [ gebner ]; platforms = platforms.unix; }; } </ins>

Discussion:
Three-Dimensional Structural Finite Element Program Website: Current stable: v2.15 Example of other distro builds:
I propose that we rename this package to calculix-ccx. Should I open a new ticket for that ? Edit: request -
Change:
<ins> { lib , buildPythonPackage , fetchPypi , setuptools , zlib , altgraph , packaging , pyinstaller-hooks-contrib , testers , pyinstaller , glibc , binutils , installShellFiles }: buildPythonPackage rec { pname = "pyinstaller"; version = "6.8.0"; pyproject = true; src = fetchPypi { inherit pname version; hash = "sha256-P0tlIPRCP+GbzC/WOrcjiFGuK9y8mPJbxdL5fMYgEuk="; }; build-system = [ setuptools ]; nativeBuildInputs = [ installShellFiles ]; buildInputs = [ zlib.dev ]; dependencies = [ altgraph packaging pyinstaller-hooks-contrib ]; makeWrapperArgs = [ "--prefix" "PATH" ":"  (lib.makeBinPath [ glibc binutils ]) ]; postInstall = '' installManPage doc/pyinstaller.1 doc/pyi-makespec.1 ''; pythonImportsCheck = [ "PyInstaller" ]; passthru.tests.version = testers.testVersion { package = pyinstaller; }; meta = { description = "A tool to bundle a python application with dependencies into a single package"; homepage = "https://pyinstaller.org/"; changelog = "https://pyinstaller.org/en/v${version}/CHANGES.html"; downloadPage = "https://pypi.org/project/pyinstaller/"; license = with lib.licenses; [ mit asl20 gpl2Plus ]; maintainers = with lib.maintainers; [ h7x4 ]; mainProgram = "pyinstaller"; }; } </ins>

Discussion:
Project description Freeze (package) Python programs into stand-alone executables. Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux, darwin
I would love to see it packaged too.
So, I did some digging on previous attempts at and found some abandoned PRs: packaged in itself but got abandoned due to complexity. was in partial effort of packaging by packaging one of its dependencies. also as a dependency for another package . Perhaps someone coming to this issue looking for the package can try it themselves using these attempts as a base.
I would also love to figure out how to build pyinstaller projects as a nix derivation
I believe you're looking for ? This issue is requesting to package itself and not packaging projects using .