jiebi/CodeConvo huggingface dataset:
Change:
stdenv.mkDerivation rec { pname = "plano-theme"; <del> version = "3.30-3"; </del> <ins> version = "3.32-1"; </ins> src = fetchFromGitHub { owner = "lassekongo83"; repo = pname; rev = "v${version}"; <del> sha256 = "1rb9whr5r2pj6fmwa9g0vdrfki3dqldnx85mpyq07jvxkipcdq6g"; </del> <ins> sha256 = "0p9j4p32489jb6d67jhf9x26my0mddcc6a174x713drch8zvb96l"; </ins> }; buildInputs = [ gdk_pixbuf gtk_engines ];

Discussion:
In current master branch pythonPackages.mysqlclient fails to build. Checkout nixpkgs on revision and run: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Most likely caused by . Unfortunately, the config-tools are not very configuration friendly. Until is resolved, I would add to the package.
Unfortunately this does not change anything, still failing with the same error message..
Hmm, apparently just hardcodes the path without the ability to override it from the attrset passed to : Is that intentional, Until this is resolved, you can use :
Change:
in '' runHook preInstallCheck <ins> (($(ulimit -n) < 1024)) && ulimit -n 1024 </ins> HOME="$(mktemp -d)" ${LD_LIBRARY_PATH}="$lib/lib" ./test/unittest ${toString excludes}

Discussion:
Attempt to build duckdb on macOS. See eg n/a Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks and !
Change:
buildPythonPackage rec { pname = "python-csxcad"; <del> version = "unstable-2020-02-18"; </del> <ins> version = csxcad.version; </ins> <del> src = fetchFromGitHub { owner = "thliebig"; repo = "CSXCAD"; rev = "ef6e40931dbd80e0959f37c8e9614c437bf7e518"; sha256 = "072s765jyzpdq8qqysdy0dld17m6sr9zfcs0ip2zk8c4imxaysnb"; }; </del> <ins> src = csxcad.src; </ins> sourceRoot = "${src.name}/python";

Discussion:
Package name: OpenEMS Latest released version: 0.0.36 <!-- Search your package here: --- Current version on the unstable channel: 2020-02-15 Current version on the stable/release channel: 2020-02-15 <!-- 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:
}); in { <del> subversion_1_10 = common { version = "1.10.8"; sha256 = "sha256-CnO6MSe1ov/7j+4rcCmE8qgI3nEKjbKLfdQBDYvlDlo="; }; </del> subversion = common { version = "1.14.2"; sha256 = "sha256-yRMOjQt1copm8OcDj8dwUuZxgw14W1YWqtU7SBDTzCg=";

Discussion:
While checking why we have two subversion releases I noticed that both releases are LTS versions. They receive 4 years of support and 1.10 was first released on 2018-04-13, so it's probably wise to remove it before the 22.05 release. Originally posted by in
I don't see anything that depends on in nixpkgs (anymore), so IMO we can just remove it now, instead of waiting for some kind of EOL announcement.
Change:
owner = "getting-things-gnome"; repo = "liblarch"; rev = "v${version}"; <del> sha256 = "0xv2mfvyzipbny3iz8vll77wsqxfwh28xj6bj1ff0l452waph45m"; </del> <ins> sha256 = "sha256-A2qChe2z6rAhjRVX5VoHQitebf/nMATdVZQgtlquuYg="; </ins> }; checkInputs = [

Discussion:
Steps to reproduce the behavior: to build liblarch at tests Relevant to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
This fail is somewhere in the last 12 days.
Surely since PR merged in .
Not sure what have broke, but adding buildInputs with gtk3 seems to fix it.
If I had to guess, this may have been caused by just like or .
Change:
pythonImportsCheck = [ "hy" ]; <ins> passthru = { tests.version = testers.testVersion { package = hy; command = "hy -v"; }; # also for backwards compatibility with removed pkgs/development/interpreters/hy withPackages = python-packages: (toPythonApplication hy).override { hyDefinedPythonPackages = python-packages; }; }; </ins> meta = with lib; { <del> description = "Python to/from Lisp layer"; homepage = "https://github.com/hylang/hy"; </del> <ins> description = "A LISP dialect embedded in Python"; homepage = "https://hylang.org/"; changelog = "https://github.com/hylang/hy/releases/tag/${version}"; </ins> license = licenses.mit; <del> maintainers = with maintainers; [ fab ]; </del> <ins> maintainers = with maintainers; [ fab mazurel nixy thiagokokada ]; </ins> }; }

Discussion:
The one in is more up-to-date (1.0a3 vs 1.0a1, current version is 1.0a4 though), . The second one is the oldest though. Not sure what is the best solution here. It doesn't seem to make much sense to have Hy being considered a interpreter instead of a Python package (it even has attribute that AFAIK isn't any different from simply from using with and other dependencies as ). But I don't have sufficient context here. We probably need to merge one in another and delete the other derivation. Steps to reproduce the behavior: We should only have one Hy package. N/A N/A <!-- 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.
Created a PR removing and keeping , while also making has the same parameter for backwards compatibility:
Change:
cp wrapper.c $out ''; <del> tests = let names = [ "add-flags" "argv0" "basic" "chdir" "combination" "env" "inherit-argv0" "invalid-env" "prefix" "suffix" "overlength-strings" ]; f = name: lib.nameValuePair name (makeGoldenTest name); in builtins.listToAttrs (builtins.map f names); in writeText "make-binary-wrapper-test" '' ${lib.concatStringsSep "n" (lib.mapAttrsToList (_: test: '' "${test.name}" "${test}" '') tests)} </del> <ins> tests = lib.genAttrs [ "add-flags" "argv0" "basic" "chdir" "combination" "env" "inherit-argv0" "invalid-env" "overlength-strings" "prefix" "suffix" ] makeGoldenTest // lib.optionalAttrs (! stdenv.isDarwin) { cross = pkgsCross.aarch64-multiplatform.callPackage ./cross.nix { }; }; in writeText "make-binary-wrapper-tests" '' ${lib.concatStringsSep "n" (builtins.attrValues tests)} </ins> '' // tests

Discussion:
making a pr fixing cross compilation for some things and found this
... and defaults to which is per shrug : /
Something that seems to fix the problem, weirdly, is to add to instead of , and use in I have no idea what's going on, need a cross-compilation guru ( ?).
is special: All packages in a package set are host→target (e.g. the normal attribute), however is derived from and re-exposed as the thing that builds this package set. This gives rise to the inconsistency that is one of the few attributes in the package set that's build→host. Putting into (where it conceptually belongs) will of course pick , since it itself comes from . To pick the default compiler we should use to build here, it should take by default where would then be the package set produced by which is the actual cross compiled set: . We need to jump through these hoops because, unfortunately the default compiler / libc etc. picking logic is only done as part of picking the 's from the previous package set.
Do you mean host→target here?
Yes, fixed.
Attempting a fix in
Thanks for reporting this Artturin! Verified the PR that was made and merged :)
Change:
substituteInPlace scripts/zmdbbackup.in  --replace /usr/bin/mysqldump ${mysql.client}/bin/mysqldump <ins> substituteInPlace scripts/zmupdate.pl.in  --replace "'mysql'" "'${mysql.client}/bin/mysql'"  --replace "'mysqldump'" "'${mysql.client}/bin/mysqldump'" </ins> for f in scripts/ZoneMinder/lib/ZoneMinder/Config.pm.in  scripts/zmupdate.pl.in  src/zm_config.h.in 

Discussion:
Zoneminder, but it seems there is no code that handles upgrades, while that is provided by upstream and for example the Ubuntu packaging. It seems to be more of a developer preview version on NixOS than something that could be used by end-users in a production environment. I would have a flag like that needs to be set to true before it does something for that reason. I welcome the progress that has been made, but it doesn't appear to be in good enough shape to compete with other solutions. I will open another issue for adding declarative camera support (), because there was another user who also wanted to have that, which should also make this issue smaller.
Looking at zoneminder_1.30.4+dfsg- in debian/TODO.Debian it says: and there is no mention of the in the scripts. Are you sure Ubuntu has support for this? My personal opinion is that automatic upgrades are not such a great thing. While there are provided migrations to upgrade the database, there doesn't seem to be an official way to downgrade. This conflicts with the nature of Nix where we expect seamless version changes in any direction. Having user manually run ensures that they are aware of the upgrade and prepared for consequences.
has recently changed, but I have seen it upgrade automatically and there was at some point some code for doing it automatically. The manual part here only seems to be the ppa configuration. The main point is that the effort required on Ubuntu is less than on NixOS.
Yes, I see that this PPA with an unofficial zoneminder package (from Ubuntu standpoint) does indeed run in its zoneminder.postinst script.
I wasn't aware of this issue until just now, hence the rather late reply. That is correct - so far we have only released a single version in nixpkgs but of course it will come back and bite us. Things can break in unstable - nothing new there and unless we hit security issues, new versions will not be back-ported, so that at least gives us to 19.09 to sort out. What other options (packaged for NixOS) do we have? I personally have very strong reservations about the architectural choices the ZM developers have made, but I am not aware of any real alternative ATM. Declarative camera support is definitely a good idea.

I support for ZM because I needed it and it solves my problem right now (until we need to update of course), but any PR would be very much welcome.
The is already part of the package - we just don't do anything with it and according to the comment in the header: But then of course it does have functionality for dealing with a number of changes. So the short version - someone just has to write (and test) how it behaves when upgraded and ensure this runs. I am realistically not going to work on that right now though.
Change:
if [[ -z $flake ]]; then pathToConfig="$(nixBuild '<nixpkgs/nixos>' -A vm -k "${extraBuildFlags[@]}")" else <del> echo "$0: 'build-vm' is not supported with '--flake'" >&2 exit 1 </del> <ins> nix "${flakeFlags[@]}" build "$flake#$flakeAttr.config.system.build.vm"  "${extraBuildFlags[@]}" "${lockFlags[@]}" pathToConfig="$(readlink -f ./result)" </ins> fi elif [ "$action" = build-vm-with-bootloader ]; then if [[ -z $flake ]]; then pathToConfig="$(nixBuild '<nixpkgs/nixos>' -A vmWithBootLoader -k "${extraBuildFlags[@]}")" else <del> echo "$0: 'build-vm-with-bootloader' is not supported with '--flake'" >&2 exit 1 </del> <ins> nix "${flakeFlags[@]}" build "$flake#$flakeAttr.config.system.build.vmWithBootLoader"  "${extraBuildFlags[@]}" "${lockFlags[@]}" pathToConfig="$(readlink -f ./result)" </ins> fi else showSyntax

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:
hash = "sha256-x2c4c9RSrNWGqEngio4ArW7dJjW0gg+8nqBwPcR721k="; }; <ins> # Fix index out of bounds reading RPATH (cherry-picked from 0.10-dev) patches = [ ./rpath.patch ]; </ins> nativeBuildInputs = [ cmake llvmPackages.llvm.dev

Discussion:
The output is From some quick searching, people on other distros who've encountered something like this have been advised to delete . That doesn't seem to help here, unfortunately. I tried making a meaningless change to one zig-dependent package in Nixpkgs, but that package still built fine with . I'm obviously not knowledgeable about Zig at all, so I'm not sure if this is a serious issue. Please run and paste the result.
It won't reproduce on x86-64 darwin. Does anyone have the same problem on NixOS? My environment:
I have the same problem, i pull from latest branch, here's my info:
I know that this is fixed upstream: and will be released in . Meanwhile, I've made an ugly overlay: to build from of and autogenerated code now builds and runs just fine, as it should.
There is also which provides many more versions.
If you prefer building zig on your computer, you can take a look at this repository as well: Flake and overlay on the branch always build the latest zig.
Why not a patch?
Change:
<ins> From 4bf0be64fe51a9c9fd9e410ada15251378b743bf Mon Sep 17 00:00:00 2001 From: Dominique Martinet <asmadeus@codewreck.org> Date: Sat, 26 Aug 2023 09:28:59 +0900 Subject: [PATCH] env.js: fix httpSafePort handling It has been clarified that this is only a dev option that should not be used in production, but setting the value in config was still ignored, so fix the init code to consider the config value and make it clear that this port is not bound if safeOrigin is set. --- config/config.example.js | 3 ++- lib/env.js               | 5 +++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/config/config.example.js b/config/config.example.js index 7c8184c6c2f6..77263643c354 100644 --- a/config/config.example.js +++ b/config/config.example.js @@ -89,8 +89,9 @@ module.exports = { /*  httpSafePort purpose is to emulate another origin for the sandbox when *  you don't have two domains at hand (i.e. when httpSafeOrigin not defined). - *  It is meant to be used only in case where you are working on a local + *  It is meant to be used only in case where you are working on a local *  development instance. The default value is your httpPort + 1. + *  Setting this to 0 or setting httpSafeOrigin disables this listener. * */ //httpSafePort: 3001, diff --git a/lib/env.js b/lib/env.js index d3748750f21e..f0660cba3e11 100644 --- a/lib/env.js +++ b/lib/env.js @@ -74,8 +74,9 @@ module.exports.create = function (config) { if (typeof(config.httpSafeOrigin) !== 'string') { NO_SANDBOX = true; -        if (typeof(config.httpSafePort) !== 'number') { httpSafePort = httpPort + 1; } httpSafeOrigin = deriveSandboxOrigin(httpUnsafeOrigin, httpSafePort); +        // only set if httpSafeOrigin isn't set. +        httpSafePort = isValidPort(config.httpSafePort) ? config.httpSafePort : (httpPort + 1); } else { httpSafeOrigin = canonicalizeOrigin(config.httpSafeOrigin); } @@ -115,7 +116,7 @@ module.exports.create = function (config) { permittedEmbedders: typeof(permittedEmbedders) === 'string' && permittedEmbedders? permittedEmbedders: httpSafeOrigin, removeDonateButton: config.removeDonateButton, -        httpPort: isValidPort(config.httpPort)? config.httpPort: 3000, +        httpPort: httpPort, httpAddress: typeof(config.httpAddress) === 'string'? config.httpAddress: 'localhost', websocketPath: config.externalWebsocketURL, logIP: config.logIP, -- 2.45.2 </ins>

Discussion:
Project description CryptPad is a collaborative office suite that is end-to-end encrypted and open-source. Enable this a service for NixOS. Metadata homepage URL: source URL: license: agpl2 platforms: unix, linux, darwin, ...
CryptPad used to be included in nixpkgs, but it was removed because there weren't enough maintainers. The removal occurred with the commits and .
Not quite true: it was removed because they had a strong dependency on out-of-date software. . Now, there is an ongoing effort to re-introduce it in : .
Change:
convchain = callPackage ../tools/graphics/convchain {}; <ins> cordless = callPackage ../applications/networking/instant-messengers/cordless { }; </ins> coursera-dl = callPackage ../applications/misc/coursera-dl {}; coyim = callPackage ../applications/networking/instant-messengers/coyim {};

Discussion:
Project description " The Discord terminal client you never knew you wanted. " aka, a Discord CLI client. Metadata homepage URL: source URL: license: bsd3 platforms: linux
Change:
}; systemd.enableCgroupAccounting = mkOption { <del> default = false; </del> <ins> default = true; </ins> type = types.bool; description = '' Whether to enable cgroup accounting.

Discussion:
I want to see systemd services in netdata monitoring. For that "cgroup accounting" is needed. The question is if enabling it on all systems would have any negative effect. In that case i would activate it only when netdata service is enabled. Arch Linux, Ubuntu and Fedora seem to have it enabled by default. debian not. shows no resources for services. System: NixOS 17.03.1700. (Gorilla) Nix version: nix-env (Nix) 1.11.13 Nixpkgs version: "17.03.1700." Sandboxing enabled: build-use-sandbox = true
I will implement it as option, that is enabled by default and for netdata service.
I believe you can set this with: And maybe also: (ideas from )
sure, that is how i do it right now. But i want to propose it to be enabled by default, so you have it when you need it for debugging. But also a single option to disable it when you have reasons to.
Is this still open for the discussion about defaulting to or is this still open simply because it wasn't closed? Unless something else than the PR is required? (
I created this issue to have this enabled for netdata. So an additional PR needs to be created to enable the new option when netdata is enabled. In addition it could be discussed to enable the option by default when a desktopManager is enabled (for desktop users). It should not be enabled by default on servers because it could have a little impact on performance.
Nowadays, this might already be enabled per default half-way: from my `systemd- (latest master right now) Are there any recent figures about performance implications when enabling the rest? If Fedora enables it, we could probably do so too.
this might already be enabled per default half-way thanks for noticing! can you create an issue or PR to change ? Are there any recent figures about performance implications when enabling the rest? i don't know any. i have no issues on my servers where i set it manually
Change:
<del> { lib, fetchzip, buildGoModule, nixosTests }: </del> <ins> { lib, fetchzip, buildGo123Module, nixosTests }: </ins> <del> buildGoModule rec { </del> <ins> buildGo123Module rec { </ins> pname = "traefik"; <del> version = "3.1.2"; </del> <ins> version = "3.1.4"; </ins> # Archive with static assets for webui src = fetchzip { url = "https://github.com/traefik/traefik/releases/download/v${version}/traefik-v${version}.src.tar.gz"; <del> hash = "sha256-PHS4x9RDoc2zDPS1SaYYEeZVa4SyQpvqzPT/SDo1ygg="; </del> <ins> hash = "sha256-e77PCMeN6Ck6hQ3Rx7MU4EL+f/1kpA2E+gVcISoUnf4="; </ins> stripRoot = false; }; <del> vendorHash = "sha256-xQPDlwu/mRdyvZW0qSCA9eko9pOQAMwh2vVJWzMnyfs="; </del> <ins> vendorHash = "sha256-iYwA/y9AuHomyEckOyl4845lkQkeBAFDsGiZWESylqs="; </ins> subPackages = [ "cmd/traefik" ];

Discussion:
Package name: traefik Latest released version: 3.1.4 Current version on the unstable channel: 3.1.2 Current version on the stable/release channel: 3.1.2 Should bump to at least 3.1.3, as it fixes Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Note for the maintainer: Traefik 3.1.4 requires Go = 1.23.0
Change:
substituteInPlace setup.py --subst-var out patchShebangs bin/ulauncher-toggle substituteInPlace bin/ulauncher-toggle  <del> --replace wmctrl ${wmctrl}/bin/wmctrl </del> <ins> --replace-fail wmctrl ${wmctrl}/bin/wmctrl </ins> ''; # https://github.com/Ulauncher/Ulauncher/issues/390

Discussion:
When using the package , some extensions (like ) require the python package . When running without it, I get the error Steps to reproduce the behavior: package with plugin and run again with crashes and log report errors The extension doesn't crash Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
ppdeep = callPackage ../development/python-modules/ppdeep { }; <ins> private-gpt = callPackage ../development/python-modules/private-gpt { }; </ins> prodict = callPackage ../development/python-modules/prodict { }; prometheus-pandas = callPackage ../development/python-modules/prometheus-pandas { };

Discussion:
Project description Interact privately with your documents using the power of GPT, 100% privately, no data leaks Metadata homepage source license: asl-2 platforms: all?
i am really new to nix, and i made this by adding dependency until it worked.. but hopefully a good starting point now just need to do is, which will download the models and to run it.
Change:
rocksdb = callPackage ../development/libraries/rocksdb { }; <ins> rocksdb_8_11 = rocksdb.overrideAttrs rec { pname = "rocksdb"; version = "8.11.4"; src = fetchFromGitHub { owner = "facebook"; repo = pname; rev = "v${version}"; hash = "sha256-ZrU7G3xeimF3H2LRGBDHOq936u5pH/3nGecM4XEoWc8="; }; }; </ins> rocksdb_8_3 = rocksdb.overrideAttrs rec { pname = "rocksdb"; version = "8.3.2";

Discussion:
The new version of stalwart mail (0.7.0), has changed a lot and the module needs a rewrite for a while now, for example: I have forked nixpkgs, to remove the standard settings, to allow me to make a more complex setting. issues I see. No way to disable the default options, in: . WebUI is not currently supported The package imports the entire . <!-- 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]:
If you want to make a contribution, even a small one, im happy to help you get it merged !
I can take a look, as I have written quite extensive configuration for my Stalwart instance. I can check it out to make it available as a NixOS module
That would be amazing ! There is an open pr from the bot for the 0.7 upgrade, you can take over that one or make the update in a new pr. Thank you !
WIP module. I haven't tested it out yet. I will probably do so this evening:
Not yet entirely fixed, module and test need some work to support = 0.7.0
By the way, since migrating to stalwart = 0.7 requires some manual migration in any case, would it be worth setting the default database type to rocksdb instead of sqlite in the module?
In my opinion yes, for the love of Linux or just make it undefined. Do you have a git repo, where I can track your progress and when I have time, give improvements?
Change:
<ins> { lib , stdenv , fetchFromGitHub , makeWrapper , meson , ninja , pkg-config , hyprland-protocols , hyprland-share-picker , inih , libdrm , mesa , pipewire , systemd , wayland , wayland-protocols , wayland-scanner }: let source = import ./source.nix { inherit lib fetchFromGitHub wayland; }; in stdenv.mkDerivation { pname = "xdg-desktop-portal-hyprland"; inherit (source) src version meta; strictDeps = true; depsBuildBuild = [ pkg-config ]; nativeBuildInputs = [ makeWrapper meson ninja pkg-config wayland-scanner ]; buildInputs = [ hyprland-protocols inih libdrm mesa pipewire systemd wayland wayland-protocols ]; mesonFlags = [ "-Dsd-bus-provider=libsystemd" ]; postInstall = '' wrapProgram $out/libexec/xdg-desktop-portal-hyprland --prefix PATH ":" ${lib.makeBinPath [hyprland-share-picker]} ''; } </ins>

Discussion:
Project description A wlroots-compatible Wayland color picker that does not suck. Metadata homepage URL: source URL: license: platforms: linux Just because you made available on NixOS, I wanted to point you on hyprpicker, too - if you're interested to have a look into this(?)
I'll take a look into packaging this.