jiebi/CodeConvo huggingface dataset:
Change:
cirrusgo = callPackage ../tools/security/cirrusgo { }; <del> inherit (callPackages ../applications/networking/remote/citrix-workspace { }) </del> <ins> inherit (callPackage ../applications/networking/remote/citrix-workspace { }) </ins> citrix_workspace_23_02_0 citrix_workspace_23_07_0 citrix_workspace_23_09_0

Discussion:
The NixOS tests for netbox are failing to evaluate: It seems like the module tries to override the package to pass in the plugins that are configured in the module, but for some reason it's overriding the function in instead of the one in . The former doesn't have a plugins argument, so that causes this error. You can also replicate this in : I don't really know what changed to cause this to happen, as it doesn't seem like it should. Steps to reproduce the behavior: The system configuration should evaluate. <!-- 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]:
Possibly related issue with an which used to work: Ping
The thing these packages have in common seems to be that they use to pull in a few different versions into . It seems like something changed about recently.
I think you're right, That commit changes to for a bunch of packages, including citrix_workspace and netbox.
Change:
<ins> { lib , stdenv , fetchFromGitHub , meson , ninja , pkg-config , wayland , wayland-protocols , libxkbcommon , cairo , gdk-pixbuf , scdoc }: stdenv.mkDerivation { pname = "waylogout"; version = "unstable-2023-06-09"; src = fetchFromGitHub { owner = "loserMcloser"; repo = "waylogout"; rev = "f90e1b8b0f67a2694fafca7beb32828493f3f78e"; hash = "sha256-YQtX4t6q2NybuKU3lVcn5XhC0nXcPfEbcXbuFmDZOrw="; }; nativeBuildInputs = [ pkg-config meson ninja scdoc ]; buildInputs = [ wayland wayland-protocols libxkbcommon cairo gdk-pixbuf ]; meta = with lib; { description = "A graphical logout/suspend/reboot/shutdown dialog for wayland"; homepage = "https://github.com/loserMcloser/waylogout"; license = licenses.mit; maintainers = with maintainers; [ dit7ya ]; platforms = platforms.linux; }; } </ins>

Discussion:
waylogout is graphical logout/suspend/reboot/shutdown dialog for wayland. It is inspired by and based on code from . Metadata license: mit platforms: linux
Change:
} ]; <ins> hardware.wirelessRegulatoryDatabase = true; </ins> environment.etc = with pkgs; { "NetworkManager/NetworkManager.conf".source = configFile;

Discussion:
Newer kernels (4.15+) can look for wireless regulatory info from (for us this is I think?), replacing the need for user-space helper like . (at least in the common case, I believe) <-- latest CRDA git adds note about this Not the same as the regdb, although I'm not sure the difference is as important for NiXOS'ers compared to other distributions. Info on internal:
I don't want to hijack the thread but my problem may be related. Recently, not sure why, I can't connect to an AP I previously could connect to so I suspect it's my machne (my phone can still access it), thus I've been looking at wifi information. I used to have a plain error then I while now it at least attempt to connect: so I wonder if it's expected on nixos ? NB: it's annoying all these errors when building kernels. do others have it too (I should probably look at hydras rather...
To get the file loaded, you need to add to . ` to see the files. Then you should see the following in : I haven't quite figured out what the best way to set the correct regulatory domain is however... short of just using .
oh great thanks ! that was not obvious. I was looking for a setting to set on boot as a kernel parameter but haven't found it yet. Some interesting read suggests one can embed the kernel in the db as well ?!
Something like this should work: Admittedly not ideal since it only works at module load time though.
Thanks Setting the following gives me the correct wifi config (check with ): Looking through the documents on: It seems to be a bit of a mess.... is an 'old' option, but NetworkManager has no support for setting the reg domain. I think having a module (?) might be a very good idea, and such an option should be to. ArchLinux deals with it by using a custom rule to run when is loaded ([source][al]). [al]: Another idea would be to a option, though that doesn't fix NetworkManager.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me".

This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
This should not be stale I think. Should NixOS just add to as default?
cc
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
} ]; <ins> environment.systemPackages = [ mastodonTootctl ]; </ins> systemd.services.mastodon-init-dirs = { script = '' umask 077

Discussion:
When one installs mastodon via the following minimal config: Then there is no obvious way to run tootctl. or any other login user doesn't have the executable by default, nor can this be enabled in an obvious way. is not a login user, so can't (and shouldn't?) log in as and execute . Steps to reproduce the behavior: mastodon as per minimal config above ... nope. ... nope. ... nope. ... nope. Any of: a setting such that is installed for that user an explanation in the docs what to do as a login user (probably bad idea?) Workaround: CC
I think upstream intends only to be run by the mastodon user. My way for doing that is just running and continuing in that shell. The reason why doesn't work is probably because sudo inherits PATH from the user you are coming from? I'm not sure I understand the concept of a login user enough. How would mastodon become a login user and why would that be a bad idea?
In the mastodon docs, it is described the following way: But is not possible, it gives the error They do recommend (which is what I meant by it shouldn't be a login user), but still they seem to do something different than nixos does. Maybe that's fine, and it would be helpful to document this somewhere, so people don't spend a long time trying to find it out.
This is default for almost all service users because they have no login shell. Use ` This is wrong. Sudo resets all path like variables like PATH and PYTHON PATH. Also inheriting needs to be turned on explicitly and PATH mist always ve inherited explicitly. Other services like nextcloud include a wrapper that sudos to the right user. This should be for mastodon, too.
Sounds like a good solution. Then we could make the command globally available.
That isn't? I would have expected that it is very similar to nextcloud-occ.
No currently it is only available to the mastodon user, so tootctl never gets called as the wrong user.
There is a hack in the nixos nextcloud-occ script that automatically sudoes if called by a different user. This could be adapted to tootctl I think.
Yes, this should be adapted. Changing the mastodon to a login user would not be the correct fix.
Change:
rm -vf BUILD ''; <ins> preBuild = '' export LD_LIBRARY_PATH=$(pwd):$LD_LIBRARY_PATH ''; </ins> NIX_CFLAGS_COMPILE = stdenv.lib.optionalString stdenv.cc.isClang "-Wno-error=unknown-warning-option"; enableParallelBuilds = true;

Discussion:
If I try to use the grpc package from the current unstable channel, then this builds only the static libraries. I tried to add to the , then cmake tries to build the shared libraries, but fails with the following error: Maybe this is an grpc issue?
I could fix it for me. The build creates a executable, which is linked to . This executable gets then used by protbuf as a plugin to build other stuff. If it gets statically linked, everythings works. But as I try to build it dynamically, it doesn't find the library when protbuf gets executed with the plugin. So I add a hook to set the . Maybe there is a better solution, but this works for me.
Change:
"docs/yaml/objects/dep.yaml" ]; }) <ins> # Fix regression in precomputing CMAKE_SIZEOF_VOID_P # See https://github.com/mesonbuild/meson/pull/11761 (fetchpatch { url = "https://github.com/mesonbuild/meson/commit/7c78c2b5a0314078bdabb998ead56925dc8b0fc0.patch"; sha256 = "sha256-vSnHhuOIXf/1X+bUkUmGND5b30ES0O8EDArwb4p2/w4="; }) </ins> ]; setupHook = ./setup-hook.sh;

Discussion:
Steps to reproduce the behavior: Notable part: @ lines 43..48: Looks like a cmake incompatibility?? possibly connected 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. system: host os: multi-user?: sandbox: version: channels(root): channels(anna): nixpkgs:
Can you try building it manually against the latest nixpkgs-unstable revision using ?
This is really weird. Looks like something went and replace the first occurrence of in the source files with in . This is how it's supposed to look:
This was already built against the latest at the time, around an hour ago. My system flake registry pins to it. I get the same result with .
this looks completely normal. what is going on?
I have done a bisection and it appears that the first bad commit was
After bisecting Meson, this bug was introduced by and is still present in master.
Yes, I am writing a fix right now
has been merged, but do you think you could make a PR to master to have prismlauncher use its own overriden meson and another PR to staging to undo that change, so that way prismlauncher is at least fixed in the master branch sooner than a few weeks from now and when staging hits master, it won't have that temp fix anymore? Thank you again!
Note that the package that's actually broken here is . But yes using a fixed version of Meson for this sounds like a good idea.
Change:
<del> diff --git a/Cargo.lock b/Cargo.lock index 5ae2bd6..e4c6f18 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -5676,9 +5676,9 @@ dependencies = [ [[package]] name = "time" -version = "0.3.34" +version = "0.3.36" source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "c8248b6521bb14bc45b4067159b9b6ad792e2d6d754d6c41fb50e29fefe38749" +checksum = "5dfd88e563464686c916c7e46e623e520ddc6d79fa6641390f2e3fa86e83e885" dependencies = [ "deranged", "itoa", @@ -5699,9 +5699,9 @@ checksum = "ef927ca75afb808a4d64dd374f00a2adf8d0fcff8e7b184af886c3c87ec4a3f3" [[package]] name = "time-macros" -version = "0.2.17" +version = "0.2.18" source = "registry+https://github.com/rust-lang/crates.io-index" -checksum = "7ba3a3ef41e6672a2f0f001392bb5dcd3ff0a9992d618ca761a11c3121547774" +checksum = "3f252a68540fde3a3877aeea552b832b40ab9a69e318efd078774a01ddee1ccf" dependencies = [ "num-conv", "time-core", </del>

Discussion:
The czkawka package is missing ffmpeg as a dependency. If ffmpeg is not found you get this error when trying to compare video files: Ignore the snap part, it throws this error when it can't find ffmpeg, regardless if snap or not. 't have ffmpeg installed on you system. comparing videos in czkawka throws error ffmpeg error. Just works. No error. Just works. First issue I've reported here, hopefully I'm doing this right. <!-- 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]:
Before I propose any changes, let me know a thing or two. When you install both ffmpeg and czkawka, then czkawka finds ffmpeg, correct?
Correct. It finds it no problem.
Change:
Keras = callPackage ../development/python-modules/keras { }; <ins> keras-applications = callPackage ../development/python-modules/keras-applications { }; keras-preprocessing = callPackage ../development/python-modules/keras-preprocessing { }; </ins> Lasagne = buildPythonPackage rec { name = "Lasagne-${version}"; version = "0.1";

Discussion:
seem the Keras preprocessing routines were split off into their own package in 2.0. The Nix version was then updated to 2.0 in commit without verifying that it worked. This broke the package as it is now necessary to also package the new package and provide it as a dependency to
We do semi-automatic batch upgrades to the Python packages because not all of them are well maintained. This also means we cannot fix all breakage that occurs during these batch upgrades, however we try to fix as much as possible. If you have the time, please package the new dependency and make a pull request.
Thanks for taking care of that.
Change:
, buildNpmPackage , nodejs_20 , fetchFromGitHub <del> , python3 </del> <ins> , python311 </ins> , darwin , nixosTests , xcbuild

Discussion:
Steps to reproduce the behavior: bitwarden-cli on aarch64-linux using nixos-unstable () Builds on x86_64-linux. Downgrading python to 3.11 can fix it. <!-- 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:
"--bin=codelldb" ]; <ins> postFixup = '' mkdir -p $out/share # codelldb expects libcodelldb.so to be in the same # directory as the executable, and can't find it in $out/lib. # To make codelldb executable as a standalone, # we put all files in $out/share, and then wrap the binary in $out/bin. mv $out/bin/* $out/share cp $out/lib/* $out/share ln -s ${lldb.lib} $out/lldb makeWrapper $out/share/codelldb $out/bin/codelldb  --set-default LLDB_DEBUGSERVER_PATH "${lldb.out}/bin/lldb-server" ''; </ins> patches = [ ./adapter-output-shared_object.patch ]; # Tests are linked to liblldb but it is not available here.

Discussion:
I want to use (providing ) for it's Debug Adapter support. Particularly it seems like Helix can utilize it with some early debugging support. However, it doesn't seem to work. After adding that to my nix shell, and entering it, and trying to run it, I get:
cc: since I'm running your latest PR bumping this.
I suspect that vscode-lldb's fork of lldb needs to be updated?
Oh yeah, that would be because the adapter is patched-inline in the extension process and the unwrapped, useless, adapter is passed thru instead.
I have some work that fixes this: just uses regular lldb now, we can drop the "fork" with the "rust-enabled" check tries to exec-itself in certain scenarios and must be patched so that it properly calls its wrapped version But most of all, it seems like is ... just built as part of already. I'm not even sure if there's a huge point in bothering with and in general. I really wish this were less messy. was a hassle to figure out, has a bad name, the repo that you find online is old and says darwin-only. yeesh.
i got hit by this, but now it says
Actually only resolves the issue. The original issue of missing still exists somewhat. Yet a working binary can be found after that PR at Help is wanted to resolve the path issue of the adapter sub package :smilingfacewith_tear:
why was this closed? I don't think it's fixed.
Change:
backoff more-itertools pexpect <del> # backblaze-b2 requires pytest 7 to complete tests. (pytestCheckHook.override { pytest = pytest_7; }) </del> <ins> pytestCheckHook pytest-xdist </ins> ]; preCheck = '' export HOME=$(mktemp -d) ''; <del> disabledTests = [ # require network "test_files_headers" "test_integration" # fixed by https://github.com/Backblaze/B2_Command_Line_Tool/pull/915 "TestRmConsoleTool" ]; </del> disabledTestPaths = [ # requires network "test/integration/test_b2_command_line.py" <ins> "test/integration/test_tqdm_closer.py" </ins> # it's hard to make it work on nix "test/integration/test_autocomplete.py" <del> "test/unit/console_tool" </del> <ins> "test/unit/test_console_tool.py" # this one causes successive tests to fail "test/unit/_cli/test_autocomplete_cache.py" </ins> ]; postInstall = lib.optionalString (execName != "b2") ''

Discussion:
Steps to reproduce the behavior: on <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- I don't have a machine, the failure is discovered by ofborg. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Closed by
No, that fixes runtime issue . Darwin still has failing tests
Change:
stdenv.mkDerivation rec { pname = "resilio-sync"; <del> version = "2.7.3"; </del> <ins> version = "2.8.1.1390"; </ins> src = { x86_64-linux = fetchurl { <del> url = "https://download-cdn.resilio.com/${version}/linux-x64/resilio-sync_x64.tar.gz"; sha256 = "sha256-DYQs9KofHkvtlsRQHRLwQHoHwSZkr40Ih0RVAw2xv3M="; </del> <ins> url = "https://download-cdn.resilio.com/${version}/linux/x64/0/resilio-sync_x64.tar.gz"; sha256 = "sha256-XrfE2frDxOS32MzO7gpJEsMd0WY+b7TS0h/H94M7Py4="; </ins> }; i686-linux = fetchurl { <del> url = "https://download-cdn.resilio.com/${version}/linux-i386/resilio-sync_i386.tar.gz"; sha256 = "sha256-PFKVBs0KthG4tuvooHkAciPhNQP0K8oi2LyoRUs5V7I="; </del> <ins> url = "https://download-cdn.resilio.com/${version}/linux/i386/0/resilio-sync_i386.tar.gz"; sha256 = "sha256-tWwb9DHLlXeyimzyo/yxVKqlkP3jlAxT2Yzs6h2bIgs="; </ins> }; aarch64-linux = fetchurl { <del> url = "https://download-cdn.resilio.com/${version}/linux-arm64/resilio-sync_arm64.tar.gz"; sha256 = "sha256-o2DlYOBTkFhQMEDJySlVSNlVqLNbBzacyv2oTwxrXto="; </del> <ins> url = "https://download-cdn.resilio.com/${version}/linux/arm64/0/resilio-sync_arm64.tar.gz"; sha256 = "sha256-b859DqxTfnBMMeiwXlGKTQ+Mpmr2Rpg24l/GNkxSWbA="; </ins> }; }.${stdenv.hostPlatform.system} or (throw "Unsupported system: ${stdenv.hostPlatform.system}");

Discussion:
The package URLs has changed. "https://download-" no longer works, neither does "https://download-". The latest can be fetched from "https://download-" and the specific version from "https://download-", as listed on Package name: resilio-sync Latest released version: 2.8.1 <!-- Search your package here: --- Current version on the unstable channel: 2.7.3 Current version on the stable/release channel: 2.7.3 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<ins> { lib , buildPythonPackage , fetchPypi , setuptools , setuptools-scm }: buildPythonPackage rec { pname = "backports-functools-lru-cache"; version = "1.6.6"; format = "pyproject"; src = fetchPypi { pname = "backports.functools_lru_cache"; inherit version; hash = "sha256-e3DnAbpNtYwO2GcanTORsKu5vRvCTU6Qw0gPS6r8wtw="; }; nativeBuildInputs = [ setuptools setuptools-scm ]; # circular dependency: # backports-functools-lru-cache -> pytest -> wc-width -> backports-functools-lru-cache doCheck = false; pythonImportsCheck = [ "backports.functools_lru_cache" ]; meta = { description = "Backport of functools.lru_cache"; homepage = "https://github.com/jaraco/backports.functools_lru_cache"; license = lib.licenses.mit; }; } </ins>

Discussion:
Steps to reproduce the behavior: I am able to build using July 27's , but not with the more recent s.
I believe this is related to Henceforth, all python2 builds will be broken. I am trying to pin nixpkgs before this commit, and I will report back how it goes.
hey, do you mind giving a try?
I can confirm that pinning python2 to the parent of works for me. I am actually not using fahclient but another python2 package (), but the error message is identical so I didn't bother to open a new issue. Maybe can check?
Change:
-isystem) isystem_seen=1 ;; <ins> -iframework) iframework_seen=1 ;; </ins> esac fi done

Discussion:
I have a system without Command Line Tools or XCode and nix'es cmake can't find headers and tries to pick up system frameworks. Try to build this: On my system I get: System: Darwin Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: 17.09pre-git () Sandboxing enabled: no
Related to
Change:
<ins> { lib , stdenv , fetchFromGitHub , cmake , pkg-config , boost , libtorrent-rasterbar , openssl , qt5 , zlib }: stdenv.mkDerivation rec { pname = "qbittorrent-enhanced"; version = "4.6.5.10"; src = fetchFromGitHub { owner = "c0re100"; repo = "qBittorrent-Enhanced-Edition"; rev = "release-${version}"; hash = "sha256-Yy0DUTz1lWkseh9x1xnHJCI89BKqi/D7zUn/S+qC+kM="; }; nativeBuildInputs = [ pkg-config cmake qt5.wrapQtAppsHook ]; buildInputs = [ openssl.dev boost zlib libtorrent-rasterbar qt5.qtbase qt5.qttools ]; meta = { description = "Unofficial enhanced version of qBittorrent, a BitTorrent client"; homepage = "https://github.com/c0re100/qBittorrent-Enhanced-Edition"; changelog = "https://github.com/c0re100/qBittorrent-Enhanced-Edition/blob/${src.rev}/Changelog"; license = with lib.licenses; [ gpl2Only gpl3Only ]; maintainers = with lib.maintainers; [ ByteSudoer ]; mainProgram = "qBittorrent-enhanced"; platforms = lib.platforms.linux; }; } </ins>

Discussion:
Project description An unofficial version of qBittorrent featuring community enhancements such as: automatic banning of Xunlei, QQ, Baidu, Xfplay, DLBT, and Offline downloader; an option to automatically ban unknown peers from China; automatic updating of public trackers list; an option to automatically ban BitTorrent media player peers; and peer whitelisting/blacklisting. Metadata homepage URL: source URL: license: gpl2/gpl3, See platforms: unix, linux, darwin, windows
It is currently available in berberman's flake:
Change:
"dev": true }, "node_modules/@types/react": { <del> "version": "18.2.31", "resolved": "https://registry.npmjs.org/@types/react/-/react-18.2.31.tgz", "integrity": "sha512-c2UnPv548q+5DFh03y8lEDeMfDwBn9G3dRwfkrxQMo/dOtRHUUO57k6pHvBIfH/VF4Nh+98mZ5aaSe+2echD5g==", </del> <ins> "version": "18.2.33", "resolved": "https://registry.npmjs.org/@types/react/-/react-18.2.33.tgz", "integrity": "sha512-v+I7S+hu3PIBoVkKGpSYYpiBT1ijqEzWpzQD62/jm4K74hPpSP7FF9BnKG6+fg2+62weJYkkBWDJlZt5JO/9hg==", </ins> "dev": true, "dependencies": { "@types/prop-types": "*",

Discussion:
Vesktop opens up to a white screen. It cannot update from tray to latest version. I tried completely removing config files from Vencord but it doesn't change anything. Running Vesktop with flag --disable-gpu makes the Vesktop stuck at loading Steps to reproduce the behavior: Vesktop Launching Vesktop should open up the app normally ! Kernel: 6.5.7-xanmod1 Gpu: AMD (mesa 23.1.7)
vencorddesktop command doesn't output any logs. When doing update from the gui, it doesn't show anything. Only time it shows something is when i try updating from tray icon. The output is the following:
This is a problem with Vencord. It is currently broken with the curren versions of Discord (including the web app) We have to wait for upstream to fix these issues and release a new version of vencord
Alright, thank you for the fast response! Cheers
I encountered the same issue, and can confirm it is fixed when the system version of vencord is 1.6.0.