jiebi/CodeConvo huggingface dataset:
Change:
<del> { callPackage, fetchpatch }: callPackage ./generic.nix { version = "2.0.0"; sha256 = "1zbf6bdpps8369r1ql00irxrp58jnalycc8jcapb8iqg654vlfz8"; patches = [ # Pull patch pending upstream inclustion for gcc-12 support: #  https://github.com/google/flatbuffers/pull/6946 (fetchpatch { name = "gcc-12.patch"; url = "https://github.com/google/flatbuffers/commit/17d9f0c4cf47a9575b4f43a2ac33eb35ba7f9e3e.patch"; sha256 = "0sksk47hi7camja9ppnjr88jfdgj0nxqxy8976qs1nx73zkgbpf9"; }) ]; } </del>

Discussion:
We define two packages, one for version 1.12 and one for version 2.0. The package for version 1.12 . Upstream has the fixes needed but only for version 2.0. The version 1.12 branch does not appear maintained, and there to it since March of 2020. We can continue to maintain this (e.g. we can disable warnings, or we can adapt those fixes to 1.12 and patch them), but perhaps we could drop support for the old version altogether? ZHF: /cc
Disabling -Werror is always reasonable, but if there's no users left in nixpkgs I think it's ok to drop it. Unless the maintainer or someone else still has a use for this (do a scream test by removing it, I guess)
is unused and can be safely removed.
Change:
wantedBy = [ "multi-user.target" ]; serviceConfig = { Restart = "on-failure"; <del> SuccessExitStatus = "2 3 4"; </del> <ins> SuccessExitStatus = "3 4"; </ins> RestartForceExitStatus="3 4"; User = cfg.user; Group = cfg.group;

Discussion:
can panic/die and systemd still thinks the service exits successfully. Steps to reproduce the behavior: syncthing: . out of disk space, syncthing panics and exits. to see that syncthing.service has deactivated successfully, even though it prints . I expect that when syncthing.service stops due to , the service gets marked as failed. I'm not sure what the exit code of syncthing is in this case (so perhaps this is an upstream issue after all), but NixOS has this syncthing.service snippet that might hide some errors: Also, here's the syncthing.service log when it failed: NixOS 22.05 (commit ).
The contains whereas the NixOS module contains
It seems that we imported from upstream in 2015: . I haven't yet found documentation for syncthing exit codes, but it's clear now that exit code is not supposed to be a "success" in 2022.
I haven't yet found documentation for syncthing exit codes EDIT: I linked to an old version, but newer ones have the same exit codes:
Change:
mkdir $out/etc/bluetooth ln -s /etc/bluetooth/main.conf $out/etc/bluetooth/main.conf <ins> # https://github.com/NixOS/nixpkgs/issues/204418 ln -s /etc/bluetooth/input.conf $out/etc/bluetooth/input.conf ln -s /etc/bluetooth/network.conf $out/etc/bluetooth/network.conf </ins> # Add missing tools, ref https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/bluez for files in `find tools/ -type f -perm -755`; do filename=$(basename $files)

Discussion:
BlueZ is currently setup to read auxiliary config files (i.e. , ) from its package directory, which makes it hard to write to them properly on a NixOS system. These configuration files are the only way to configure certain behaviours of , such as in , which is an important setting for device power saving. It's not possible to specify these options in . And it's not possible to specify the path of at runtime. Steps to reproduce the behavior: a file, either manually or from a nix configuration. with . hasn't loaded any settings from . (It's easy to test if you fill with trash since it should log: ). It should be possible to configure all aspects of in the same way. BlueZ loads from a hardcoded path: The same is try for : The define is set to the package directory by default. For a symlink is setup, however no such link is setup for or : I wonder if a fix for this might be adding to the of BlueZ? There's no maintainer listed in , so I'm pinging the people who last touched it :) , Please run and paste the result.
I feel like this could be easily fixed rather in the by adding 2 more options for and under (?) Let me see if I can carve out some time later this week..
Fixed in
Change:
cargoSha256 = "1hg8j9a8c6c3ap24jd96y07rlp4f0s2mkyx5034nlnkm3lj4q42n"; <del> nativeBuildInputs = [ cmake pkg-config installShellFiles]; buildInputs = [ openssl oniguruma ] ++ lib.optional stdenv.isDarwin CoreServices; </del> <ins> nativeBuildInputs = [ cmake pkg-config installShellFiles ]; buildInputs = [ openssl oniguruma ] ++ lib.optional stdenv.isDarwin [ CoreServices libsass ]; </ins> RUSTONIG_SYSTEM_LIBONIG = true;

Discussion:
It doesn't work with nor with a flake. Works fine on my NixOS machine. I don't even know what means. With a flake I suspect that this is related to . I've had so many dynamic linking errors in the past week, especially from Rust stuff, that I no longer have the energy to look into this myself, hence the bug report. Please run and paste the result.
Could you (or anyone with access to aarch64-darwin) try another run against my branch?
$ nix-shell -p zola error: missing bootstrap url for platform aarch64-apple-darwin (use '--show-trace' to show detailed location information) is coming from and since the flake works you should update your channels
I'm trying your commit but it might take a while for things to compile. I'll probably ask about this on Discourse since it's unrelated to this issue but I was hoping that my Darwin machine would run the I install through the flake that makes up my dotfiles. So hopefully taking channels out of the equation, but I think that's not how it works, so I'll look into this, thanks.
that should be possible but uses channels while uses flakes. remove your channels to be sure that you're using flakes instead of channels
works, thanks! If someone needs this fix right now
Thanks Here's another way of applying the fix that doesn't require a overlay, which works for my use case:
Change:
{ lib <ins> , callPackage </ins> , stdenv <ins> , chromium </ins> , fetchFromGitHub , fetchYarnDeps , makeWrapper

Discussion:
consistently fails on 23.11. Steps to reproduce the behavior: to NixOS 23.11 This should work like . Debug output: Installing via or via does not fix this. , but no mention of Chromium itself. It looks like the error message is from . . system: host os: multi-user?: sandbox: version: channels(root): channels(username): nixpkgs: (I'll be tweaking this in case I come up with a working solution.) to a new directory, for example a containing the following: the built package like this: Unfortunately, the override doesn't work as expected: ERROR: Failed to set up Chromium r982053! Set "PUPPETEERSKIP_DOWNLOAD" env variable to skip download. I'm not sure how to proceed. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Unfortunately I'm not using this anymore and should remove myself as maintainer. Any volunteers? Looks like we have a fix now too. Can anyone verify?
I'm still using it for the foreseeable, so I've .
Change:
owner = "pandas-dev"; repo = "pandas-stubs"; rev = "refs/tags/v${version}"; <del> hash = "sha256-416vyaHcSfTfkSNKZ05edozfsMmNKcpOZAoPenCLFzQ="; </del> <ins> hash = "sha256-wJ7lN1+BGNqhwgPLmmpb3foX6rIEy3R62rOvu0mr8xs="; </ins> }; <del> nativeBuildInputs = [ poetry-core ]; </del> <ins> build-system = [ poetry-core ]; </ins> <del> propagatedBuildInputs = [ pandas </del> <ins> dependencies = [ numpy </ins> types-pytz ]; nativeCheckInputs = [ <ins> pytestCheckHook </ins> beautifulsoup4 html5lib jinja2

Discussion:
Steps to reproduce the behavior: recently edited: <!-- 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]:
Change:
sed -i 's/antlr4-python3-runtime==.*/antlr4-python3-runtime/' requirements/base.txt ''; <del> nativeBuildInputs = [ </del> <ins> build-system = [ </ins> setuptools <ins> ]; nativeBuildInputs = [ </ins> jre_minimal ]; <del> propagatedBuildInputs = [ </del> <ins> dependencies = [ </ins> antlr4-python3-runtime pyyaml ];

Discussion:
Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I started with but unfortunately there is more to do.
Change:
fabric = pythonPackages.fabric; <del> fail2ban = callPackage ../tools/security/fail2ban { systemd = systemd.override { pythonSupport = true; }; }; </del> <ins> fail2ban = callPackage ../tools/security/fail2ban { }; </ins> fakeroot = callPackage ../tools/system/fakeroot { };

Discussion:
with current current unstable channel, the fail2ban package misses its etc path. The package hasn't been updated for some time and the out path is apparently generated by rewriting pathes in its : This suggests that the breakage might be related to the recent python packaging rework, so /cc as well as pkg maintainers
Change:
<ins> { lib, modulesPath, pkgs, ... }: let ssh-keys = if builtins.pathExists ../../ssh-keys.nix then # Outside sandbox ../../ssh-keys.nix else # In sandbox ./ssh-keys.nix; inherit (import ssh-keys pkgs) snakeOilPrivateKey snakeOilPublicKey; in { imports = [ (modulesPath + "/virtualisation/qemu-vm.nix") (modulesPath + "/testing/test-instrumentation.nix") ]; virtualisation.writableStore = true; nix.binaryCaches = lib.mkForce [ ]; virtualisation.graphics = false; documentation.enable = false; services.qemuGuest.enable = true; boot.loader.grub.enable = false; services.openssh.enable = true; users.users.root.openssh.authorizedKeys.keys = [ snakeOilPublicKey ]; security.pam.services.sshd.limits = [{ domain = "*"; item = "memlock"; type = "-"; value = 1024; }]; } </ins>

Discussion:
Describe the bug introduced a change that breaks NixOps. When we have a test, something like this will be detected faster and not depend on users running into an issue. That would increase the quality. To Reproduce Steps to reproduce the behavior: nixops complain :grimacing:
I marked this as stale due to inactivity. &rarr;
Tests would still be nice. has been more broken than I expected...
I marked this as stale due to inactivity. &rarr;
Change:
<del> { lib, buildPythonPackage, fetchPypi, isPy3k, alsaUtils, libnotify, which, loguru, pytest }: </del> <ins> { lib, stdenv, buildPythonPackage, fetchFromGitHub, isPy3k, coreutils, alsaUtils , libnotify, which, jeepney, loguru, pytestCheckHook }: </ins> buildPythonPackage rec { <del> pname = "notify_py"; version = "0.3.1"; </del> <ins> pname = "notify-py"; version = "0.3.3"; </ins> disabled = !isPy3k; <del> src = fetchPypi { inherit pname version; sha256 = "5ba696d18ffe1d7070f3d0a5b4923fee4d6c863de6843af105bec0ce9915ebad"; </del> <ins> src = fetchFromGitHub { owner = "ms7m"; repo = pname; rev = "v${version}"; sha256 = "1n35adwsyhz304n4ifnsz6qzkymwhyqc8sg8d76qv5psv2xsnzlf"; </ins> }; <del> postPatch = '' substituteInPlace setup.py  --replace "loguru==0.4.1" "loguru~=0.5.0" ''; propagatedBuildInputs = [ alsaUtils libnotify loguru which ]; </del> <ins> propagatedNativeBuildInputs = [ which ] ++ lib.optionals stdenv.isLinux [ alsaUtils libnotify ]; propagatedBuildInputs = [ loguru ] ++ lib.optionals stdenv.isLinux [ jeepney ]; </ins> <del> checkInputs = [ alsaUtils libnotify pytest which ]; </del> <ins> checkInputs = [ coreutils pytestCheckHook ]; </ins> <del> checkPhase = '' pytest </del> <ins> # Tests search for "afplay" binary which is built in to MacOS and not available in nixpkgs preCheck = '' mkdir $TMP/bin ln -s ${coreutils}/bin/true $TMP/bin/afplay export PATH="$TMP/bin:$PATH" </ins> ''; pythonImportsCheck = [ "notifypy" ]; meta = with lib; { <del> description = " Python Module for sending cross-platform desktop notifications on Windows, macOS, and Linux."; </del> <ins> description = "Python Module for sending cross-platform desktop notifications on Windows, macOS, and Linux."; </ins> homepage = "https://github.com/ms7m/notify-py/"; license = licenses.mit; maintainers = with maintainers; [ austinbutler ];

Discussion:
Describe the bug fails on darwin because it erroneously requires alsa-utils. To Reproduce Steps to reproduce the behavior: nix on macos BigSur 11.2.3, run error: Expected behavior I expected a shell to appear (with notify-py available in python) Screenshots Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(egk): nixpkgs: Maintainer information:
I have it working locally now, opened
Change:
<del> { stdenv, fetchgit, cmake, zlib, libpng, bzip2, libusb, openssl }: </del> <ins> { stdenv, fetchgit, cmake, zlib, libpng, bzip2, libusb1, openssl }: </ins> stdenv.mkDerivation { name = "xpwn-0.5.8git"; src = fetchgit { <del> url = "git://github.com/dborca/xpwn.git"; rev = "4534da88d4e8a32cdc9da9b5326e2cc482c95ef0"; sha256 = "1h1ak40fg5bym0hifpii9q2hqdp2m387cwfzb4bl6qq36xpkd6wv"; </del> <ins> url    = "git://github.com/dborca/xpwn.git"; rev    = "4534da88d4e8a32cdc9da9b5326e2cc482c95ef0"; sha256 = "1h1ak40fg5bym0hifpii9q2hqdp2m387cwfzb4bl6qq36xpkd6wv"; </ins> }; preConfigure = ''

Discussion:
Trying to build it fails on libusb complaining about '-no-cpp-precomp'. If you replace the libusb dependency with libusb1, it then fails with cmake trouble. Is hydra not building this stuff?
Hydra builds derivation only for the platforms set in meta.platforms. For xpwn meta.platforms is not set, thus hydra does not build it. However I don't have access to a darwin machine so I cannot help with the xpwn problem.
This PR should address similar issues:
Change:
ln -s "$desktopItem/share/applications/${executableName}.desktop" "$out/share/applications/${executableName}.desktop" ln -s "$urlHandlerDesktopItem/share/applications/${executableName}-url-handler.desktop" "$out/share/applications/${executableName}-url-handler.desktop" <ins> # These are named vscode.png, vscode-insiders.png, etc to match the name in upstream *.deb packages. </ins> mkdir -p "$out/share/pixmaps" <del> cp "$out/lib/vscode/resources/app/resources/linux/code.png" "$out/share/pixmaps/code.png" </del> <ins> cp "$out/lib/vscode/resources/app/resources/linux/code.png" "$out/share/pixmaps/vs${executableName}.png" </ins> # Override the previously determined VSCODE_PATH with the one we know to be correct sed -i "/ELECTRON=/iVSCODE_PATH='$out/lib/vscode'" "$out/bin/${executableName}"

Discussion:
VSCode/VSCodium's desktop icon (specified in the file) is set to . On the icon theme (the default dark icon theme that comes with Budgie desktop on NixOS), this makes it look like a generic text editor, and not the respective application. The issue appears to arise from how both apps use the same desktop files that were inherited from :   NixOS w/ Budgie desktop Icon theme to Qogir/Qogir-dark VSCodium/VSCode app list VSCode should use the icon VSCodium should use the icon ! My NixOS install is running in a VMWare VM.
Change:
}) ./no-create-dirs.patch ./Disable-methods-that-change-files-in-etc.patch <ins> # Fixes https://github.com/NixOS/nixpkgs/issues/72396 ./drop-prefix-check-extensions.patch </ins> # Systemd unit improvements. Notably using StateDirectory eliminating the # need of an ad-hoc script. (fetchpatch {

Discussion:
Describe the bug AccountsService refuses to read the extensions files, and emits this warning This why I believe people noticed issue, because from lightdm won't exist because of this. This is particularly problematic for Pantheon, which plans to use AccountsService extensions for a variety of things, and currently for a harmonized time_format setting. The actual warning in the source code is at and it's because this returns false. These symlinks checks are tricky for NixOS, where the symlink they expect is a symlink to a symlink to a... :smile:
cc
I would just drop the checks. The assumptions might not make sense even with FHS systems, since AccountsService uses XDGDATADIRS to find the extensions.
I think we could drop the then.

LightDM seems not installing dbus interface of AccountsService. Systemd journal: In package, it is contained: But in the current system: system: host os: multi-user?: sandbox: version: channels(root): channels(mnacamura): nixpkgs:
Hmm, apparently it is some kind of extension to : Weird that it is not linked – the lightdm module contains .
Actually, the dbus module does not use , it creates a configuration file: The directory is probably just a side effect of something adding to .
Ah I see. So, the is put in : I examined : <sI guess lightdm 's should also be included in these paths?</sNo. The interface file has .xml extension. It is not a config file.
Probably, interfaces files should be linked in ?
No idea – I thought the interface files were only for introspection or something. I tried linking to by adding it to but that does not seem to help. You can try the route but I do not see it documented anywhere. Though, I do not see the one in data dirs documented either – perhaps it is really just for applications like d-feet. But the data should be available through dbus interface so I do not see the need for installing the XML files. On a side note, for the interface symlinks in , so something like the following might be good:
Thanks for suggestion. I tried this: Apparently the interface file appears, but I still see the error.
Does this look relevant ?
Hopefully fixed by the above PR.
Change:
<ins> { fetchurl, fetchzip }: { "x86_64-darwin" = fetchzip { sha256 = "sha256-ec1l4KxKJH4Iwg9hW+xlxLADGLN1vParYaWIw7nCfKA="; url = "https://github.com/AdguardTeam/AdGuardHome/releases/download/v0.106.3/AdGuardHome_darwin_amd64.zip"; }; "i686-linux" = fetchurl { sha256 = "sha256-9aGyC76WyzwHlAkR72kuNcd/68XdWWC3gfT92IuW2LY="; url = "https://github.com/AdguardTeam/AdGuardHome/releases/download/v0.106.3/AdGuardHome_linux_386.tar.gz"; }; "x86_64-linux" = fetchurl { sha256 = "sha256-qJMymTxmoPlIhuJD6zFBWWwzz+CFx+9+MOrRiFtA4IY="; url = "https://github.com/AdguardTeam/AdGuardHome/releases/download/v0.106.3/AdGuardHome_linux_amd64.tar.gz"; }; "aarch64-linux" = fetchurl { sha256 = "sha256-Z5hekNxeemqWsMu7n3UTmYCzdKp5Xsp9ku0G2LOqC80="; url = "https://github.com/AdguardTeam/AdGuardHome/releases/download/v0.106.3/AdGuardHome_linux_arm64.tar.gz"; }; } </ins>

Discussion:
Describe the bug AdGuardHome has the meta platform , but is a . To Reproduce Try to run on (or any architecture other than ). It will fail with : Expected behavior should execute, so that it can be used. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I will try to get it instead of pulling a pre-compiled binary, but I'm not sure whether I'll get this solved. EDIT: Okay, that looks to be above my packaging skills, as the project consists of both a node component and a golang component, so it's nontrivial to package. An intermediate solution might be to use the architecture to determine the download URL, but that would make the src (and thus the hash) depend on the architecture. The downloads for different architectures .
Hotfix for aarch64 by using :
I marked this as stale due to inactivity. &rarr;
I also have the problem from the thread starter and I was wondering whether there is now official support for aarch64 (trying adguardhome on raspberrypi 3) or do I need to change smth in my config. I just use adguardhome as the inside of the systemPackages and I enable it. I also see this PR: .
the pr wasn't backported to 21.05. the pr will be in the 21.11 release which will be released today or tommorow afaik
great, thx for the info :)
Change:
<ins> { lib , stdenv , fetchFromGitHub , cmake }: stdenv.mkDerivation (finalAttrs: { pname = "libgff"; version = "2.0.0"; src = fetchFromGitHub { owner = "COMBINE-lab"; repo = "libgff"; rev = "v${finalAttrs.version}"; hash = "sha256-ZCb3UyuB/+ykrYFQ9E5VytT65gAAULiOzIEu5IXISTc="; }; nativeBuildInputs = [ cmake ]; meta = { description = "A lightweight GTF/GFF parsers exposing a C++ interface"; homepage = "https://github.com/COMBINE-lab/libgff"; downloadPage = "https://github.com/COMBINE-lab/libgff/releases"; changelog = "https://github.com/COMBINE-lab/libgff/releases/tag/" + "v${finalAttrs.version}"; license = lib.licenses.boost; platforms = lib.platforms.all; maintainers = [ lib.maintainers.kupac ]; }; }) </ins>

Discussion:
Salmon is a bioinformatics tool to produce a highly accurate, transcript level quantification estimates from short-read RNA-seq data. It's mostly written in C++. There's a similar tool already in nixpkgs (Kallisto), but they both have a few unique features, so packaging Salmon is still useful. It's also quite a popular tool. homepage URL: source URL: license: GLP v3.0 platforms: linux, others?
I started packaging it, and made good progress. It's a way for me to learn Nix, but may need a few pointers to get it done
Open a draft PR, then.
Change:
inherit version doCheck; # Blank llvm dir just so relative path works <del> src = runCommand "${pname}-src-${version}" {} '' </del> <ins> src = runCommand "${pname}-src-${version}" { } '' </ins> mkdir -p "$out" cp -r ${monorepoSrc}/cmake "$out" cp -r ${monorepoSrc}/mlir "$out"

Discussion:
Steps to reproduce the behavior: a package that depends on mlir via cmake and get the following error: Now it wasn't quite obvious to me at first, but I have a theory what is happening here: The the package has an and output, thus the static libraries end up in the output, while the cmake files end up in the output. I don't really know how output splitting works, but I guess that nix simply replaces all references to the path, for each output pretending there's only a single such out path, therefore creating a path where the static libraries don't actually exists. This is further confirmed looking at the store paths of the out output: which mlir-tblgen /nix/store/8qd7dxd0skkf6hqmfhqb5k9r3hgh61mp-mlir-17.0.6/bin/mlir-tblgen ls /nix/store/8qd7dxd0skkf6hqmfhqb5k9r3hgh61mp-mlir-17.0.6/lib/libMLIRPresburger.a /nix/store/8qd7dxd0skkf6hqmfhqb5k9r3hgh61mp-mlir-17.0.6/lib/libMLIRPresburger.a (out output store path + path from the cmake output above) ls /nix/store/8qd7dxd0skkf6hqmfhqb5k9r3hgh61mp-mlir-17.0.6/lib/cmake ls: cannot access '/nix/store/8qd7dxd0skkf6hqmfhqb5k9r3hgh61mp-mlir-17.0.6/lib/cmake': No such file or directory (no cmake in the out output store path) ls /nix/store/zjjkxmbpwxh6w8f3gg145k9zg1wvl432-mlir-17.0.6-dev/lib/ cmake (the dev output contains only cmake in the lib directory) I've built mlir locally with , and the error is gone. <!-- 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]:
Thanks for your bug report. I have to double-check this, but as you suggested, it seems that it should use the or instead of the output. I'll check it later and fix it.