jiebi/CodeConvo huggingface dataset:
Change:
+ withXenfiles (name: x: ''* ${name}: ${x.meta.description or "(No description)"}.''); platforms = [ "x86_64-linux" ]; maintainers = with stdenv.lib.maintainers; [ eelco tstrobel oxij ]; <del> }; </del> <ins> } // (config.meta or {}); </ins> } // removeAttrs config [ "xenfiles" "buildInputs" "patches" "postPatch" "meta" ])

Discussion:
Security support for Xen 4.5 (our current default version) ended January 2018, so we should change the default to 4.8 in 18.03 (and remove 4.5 in the future).
what's your opinion on this?
See .
Change:
sourceProvenance = with sourceTypes; [ binaryNativeCode ]; license = licenses.mit; platforms = platforms.linux; <del> maintainers = with maintainers; [ colamaroro bryango ]; </del> <ins> maintainers = with maintainers; [ bryango ]; </ins> knownVulnerabilities = [ "CVE-2023-5217" "CVE-2022-21718"

Discussion:
Install pulsar 109.0 on nixos stable Steps to reproduce the behavior: pulsar 109.0 on nixos stable to github fatal : 'remote-https' seem to be a git command, but could not be executed. could git-remote-https be broken? Be able to fetch pull and push Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I've been able to reproduce the issue and find the root cause. is a independent binary of just . Looking at how to fix this proprely . Not sure I can easily backport it to 23.11 tho Quick update: Turns out there isn't only (which is symlinked up to) which has issue. And I can not simply symlink the whole Git package in its place, , the library used upstream, add other file, which are not included by default in git, but are required at runtime.
Well, it wasn't as hard as I thought it was going to be. Probably not going to be able to backport because of the bump from 1.109.0 to 1.114.0, but feel free to try out the patch in , targeting Unstable :)
Change:
}: let <del> inherit (stdenv.lib) optionals optional optionalString; </del> <ins> inherit (stdenv.lib) optionals optional optionalString concatStringsSep; </ins> inherit (darwin.apple_sdk.frameworks) Security; llvmSharedForBuild = pkgsBuildBuild.llvm_10.override { enableSharedLibraries = true; };

Discussion:
With the update to 1.48, rustc is missing some host platform libraries when built as a cross-compiler. Most notably, is missing which causes cross-compiled packages with scripts to fail with the following error: The native (host == target) compiler is not affected. The diff between the native and cross directory is as follows: This seems like an upstream regression. Interestingly, the list of missing libraries exactly matches the list of libraries installed in . cc
looks kind of suspicious.
Or actually looks like it would explain the issue. I think we need to add the host platform to targets as well.
That makes sense to me and sounds like a good solution.
Change:
<ins> { lib , stdenv , fetchurl , guile , guile-fibers , guile-gcrypt , texinfo , pkg-config }: stdenv.mkDerivation rec { pname = "guile-goblins"; version = "0.11.0"; src = fetchurl { url = "https://spritely.institute/files/releases/guile-goblins/guile-goblins-${version}.tar.gz"; hash = "sha256-1FD35xvayqC04oPdgts08DJl6PVnhc9K/Dr+NYtxhMU="; }; strictDeps = true; nativeBuildInputs = [ guile pkg-config texinfo ]; buildInputs = [ guile guile-fibers guile-gcrypt ]; makeFlags = [ "GUILE_AUTO_COMPILE=0" ]; # tests hang on darwin, and fail randomly on aarch64-linux on ofborg doCheck = !stdenv.isDarwin && !stdenv.isAarch64; meta = with lib; { description = "Spritely Goblins for Guile"; homepage = "https://spritely.institute/goblins/"; license = licenses.asl20; maintainers = with maintainers; [ grxnola ]; platforms = guile.meta.platforms; }; } </ins>

Discussion:
Project description is a distributed object programming environment for Guile (a Racket version is also currently maintained). It is mantained by and is built to be the core layer for building broader decentralized networking technologies. Metadata homepage URL: https://spritely.institute/goblins/ source URL: https://spritely.institute/files/releases/guile-goblins/guile-goblins- license: Apache v2 platforms: Linux, maybe Darwin, maybe Unix
Change:
buildPythonPackage rec { pname = "terminaltables"; <del> version = "3.1.0"; </del> <ins> version = "3.1.7"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "f3eb0eb92e3833972ac36796293ca0906e998dc3be91fbe1f8615b331b853b81"; </del> <ins> sha256 = "5dab2f33927c0a020b8011c81b92830ff9fd4ba701657da5d7bfdc41048360a6"; </ins> }; meta = with lib; {

Discussion:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
, pixman , pythonOlder , udev <del> , wlroots_0_16 </del> <ins> , wlroots </ins> , wayland , pywayland , xkbcommon , xorg , pytestCheckHook <ins> , qtile </ins> }: buildPythonPackage rec { pname = "pywlroots"; <del> version = "0.16.1"; </del> <ins> version = "0.15.24"; </ins> format = "setuptools"; disabled = pythonOlder "3.7"; src = fetchPypi { inherit pname version; <del> hash = "sha256-GFJw88N0313PudM0o/jOvtoE3u8kSoV+lYgKlNya4wM="; </del> <ins> hash = "sha256-TvYhxiAbK+mpcEE9y79WH96dzeDnvI0xPaUxSYQqyHE="; </ins> }; nativeBuildInputs = [ pkg-config ]; propagatedNativeBuildInputs = [ cffi ]; <del> buildInputs = [ libinput libxkbcommon pixman xorg.libxcb udev wayland wlroots_0_16 ]; </del> <ins> buildInputs = [ libinput libxkbcommon pixman xorg.libxcb udev wayland wlroots ]; </ins> propagatedBuildInputs = [ cffi pywayland xkbcommon ]; nativeCheckInputs = [ pytestCheckHook ];

Discussion:
Steps to reproduce the behavior: Qtile This log comes from a system update (nixos-rebuild switch --upgrade). I have been using Qtile for a long time, even before I recently changed to NixOS from Gentoo, and I am quite sure that Qtile currently needs <wlroots-0.16.0, i.e. wlroots-0.15.x. A few days ago, in commit , pywlroots is updated from 0.15.x to 0.16, pinning wlroots to 0.16, and therefore breaks the dependency of Qtile. I notify both maintainers of Qtile and pywlroots, because this may require a change to both packages, providing a pywlroots015 and using that for qtile. Please run and paste the result.
Yeah, I didn't update the package on purpose when the latest version was released. The build failure can be fixed by bumping the wlroots derivation used by qtile to 0.16 as well but that breaks the Wayland backend at runtime. It's a bit unfortunate that i wasn't notified of the package being updated, since qtile is the only reverse dependency, so the update wasn't necessary at all.
Alternatively, if qtile is the only package depending on pywlroots, why not downgrade pywlroots to 0.15 and pin it to wlroots015? Later on when the new qtile is released that supports 0.16, upgrade them in tandem?
PR to revert in
cc (since you did the pywlroots bump) The pywlroots bump from and the last staging-next broke qtile (the only reverse dep of pywlroots) since qtile currently requires pywlroots 0.15 until a new release supports 0.16
So pywlroots is behind on wlroots support and qtile is behind on pywlroots support. Name a better trio, I'll wait. :clap: On a more serious note: Feel free to do the revert, I have no strong opinion on the matter. If this becomes a regular fallout on may become an option.
pywlroots is not behind on wlroots. It's only qtile which is behind on pywlroots (but qtile hasn't had a release since pywlroots 0.16).

Ah ok, so requires 0.16, but defaults to 0.15, hence the requirement for the pin. Got it.
Change:
#### Dev http://ftp.gnome.org/pub/GNOME/devtools/ <del> anjuta = callPackage ./devtools/anjuta { }; </del> devhelp = callPackage ./devtools/devhelp { }; #### Games

Discussion:
If my sources are correct, the Project was archived in 2022 and the link for the Hompage now redirects to an indonesian gambling site. Linking to the could be better, but the Homepage link (on mentioned repo) also links to the gambling site.
The github repo does not look official. That would be But maybe it is time to remove it.
Considering the archived repo also links to the lapsed domain that now redirects to a gambling site, I'd be in favour of removal. However, that will also necessitate the removal of , which hasn't seen any updates since 2015. Neither has any maintainers, so I don't think the removal is likely to be objected to.
Change:
<ins> { lib , stdenv , boost , libX11 , libXext , linuxPackages , openssl , tuxclocker-plugins }: stdenv.mkDerivation { pname = "tuxclocker-nvidia-plugin"; inherit (tuxclocker-plugins) src version meta BOOST_INCLUDEDIR BOOST_LIBRARYDIR nativeBuildInputs; buildInputs = [ boost libX11 libXext linuxPackages.nvidia_x11 linuxPackages.nvidia_x11.settings.libXNVCtrl openssl ]; # Build doesn't have a way to disable building the CPU plugin, which is already # provided by 'tuxclocker-plugins' patches = [ ./no-cpu-plugin.patch ]; mesonFlags = [ "-Ddaemon=false" "-Dgui=false" "-Drequire-nvidia=true" ]; } </ins>

Discussion:
Project description TuxClocker is a hardware controlling and monitoring program. TuxClocker consists of a DBus daemon and a Qt GUI that uses the daemon. It allows you to e.g. set a custom fan curve and overclock your CPU and GPU. Metadata homepage URL: source URL: license: gpl3 platforms: linux
Change:
buildPythonPackage rec { pname = "funcparserlib"; <del> version = "1.0.0a0"; </del> <ins> version = "1.0.0"; </ins> format = "pyproject"; disabled = pythonOlder "3.6";

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 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: <!-- The current version can be found easily with the same process as 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: desired version: <!-- 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:
}; nativeBuildInputs = [ autoreconfHook pkg-config ]; <del> buildInputs = [ pam openssl libp11 ] </del> <ins> buildInputs = [ pam libp11.passthru.openssl libp11 ] </ins> ++ lib.optionals stdenv.isDarwin [ libintl ]; meta = with lib; {

Discussion:
pam_p11 causes login segfault in NixOS 22.11. GDM and Gnome lock screen are also affected. Steps to reproduce the behavior: to log in on the console or run `: Bug was not present in 22.05.
Reverting does not help.
Fixed by: Can someone with commit access apply this patch?
Can you open a pull request with that patch?
I hope that NixOS can be unbureaucratic enough that PRs are not required for this kind of patch.
It's generally preferred to do basically everything through PRs, so some basic CI checks can run & maintainers can be pinged automatically. We can just self-merge though. I created containing your diff and adding a comment for explanation.
This seems to be whats causing my 22.11-beta19 install on an Alder Lake 12700H (no gpu) to not boot into GDM. This is a pretty heinous issue that should be tested for. The graphical installer doesn't install Vim, WPA_Supplicant or anything useful for figuring out what went wrong, despite having Vim and WPA Supplicant available on the installation media/calamares.
Well I just did - you're welcome. That's what beta releases are for, aren't they?
Change:
# remove badly packaged plugins rm $out/lib/insync/PySide2/plugins/platforminputcontexts/libqtvirtualkeyboardplugin.so <ins> # remove the unused vendor wrapper rm $out/bin/insync </ins> runHook postInstall '';

Discussion:
I have installed the latest unstable version of Insync. I start it, configure my account, and the following happens: No systry icon appears When I close the Insync window and try to start it again, it does nothing If I execute any command from the console, I get this message: Insync doesn't seem to be running. Start it first. IMPORTANT: It's seems sync continue working but I can't show the Insync window. Steps to reproduce the behavior: package package from Rofi account and all works Insync window show the Insync window again to view files or change config I should be able to reopen the Insync window and also use the commands from the console. system: host os: multi-user?: sandbox: version: nixpkgs:
I discover more things about this: It's seems the service is running! The systry icon is invisble and stay there. When I click on the invisble char the Insync open Any terminal command over Insync works !
Thanks for the report , I will be taking a look.
I have the same. and i tried with x11 and wayland, with plasma and gnome, and with configuration and with just closing the welcome screen.. Always the same. Freshly installed, you see the GUI exactly one Time.
Hey folks, it seems a hard nut to crack. I am scratching my head why this is happening. I have even looked into how buildFHSBubblwrap works. Meanwhile, if you can get a system-tray plugin for your desktop environment, you may have the luck of being able to open the interface for you. Until then, any help is welcome. I will keep digging another day!
From the system tray it opens, but since the icon is not painted you have to guess where the click is. Is there any way to launch the click action from the terminal? Thanks for investigate it! !
I should have fixed these reported problems in : When I close the Insync window and try to start it again, it does nothing If I execute any command from the console, I get this message: Insync doesn't seem to be running. Start it first.
I won't be able to fix the "No systry icon appears" issue still, it's a known bug and I suspect it's a defect in upstream closed source code.

Expecting to be available next week ish for both 23.05 and unstable.
Also to 23.05.
FYI: Also, a new package for nautilus users: please give a :+1: for faster merging!
Change:
<ins> { rustPlatform, lib, fetchFromGitHub, nix-update-script, cmake, pkg-config, fontconfig, stdenv, darwin, }: rustPlatform.buildRustPackage rec { pname = "wgpu"; version = "22.1.0"; src = fetchFromGitHub { owner = "gfx-rs"; repo = "wgpu"; rev = "refs/tags/wgpu-v${version}"; hash = "sha256-Gtq0xYZoWNwW+BKVLqVVKGqc+4HjaD7NN1hlzyFP5g0="; }; cargoLock = { lockFile = ./Cargo.lock; outputHashes = { "noise-0.8.2" = "sha256-7GvShJeSNfwMCBIfqLghXgKQv7EDMqVchJw0uxPhNr4="; "rspirv-0.11.0+sdk-1.2.198" = "sha256-AcJqkcXBr/+SHdUDXd63sQ0h5eosMqRhV4aUREJH8Bw="; }; }; nativeBuildInputs = [ cmake pkg-config ]; buildInputs = [ fontconfig ] ++ lib.optionals stdenv.hostPlatform.isDarwin ( with darwin.apple_sdk.frameworks; [ CoreServices QuartzCore AppKit ] ); #requires GPU doCheck = false; passthru.updateScript = nix-update-script { }; meta = { homepage = "https://wgpu.rs/"; description = "Cross-platform, safe, pure-Rust graphics API."; changelog = "https://github.com/gfx-rs/wgpu/releases/tag/v${version}"; maintainers = with lib.maintainers; [ bot-wxt1221 ]; license = with lib.licenses; [ mit apsl20 ]; }; } </ins>

Discussion:
Project description Rust implementation of the WebGPU standard, right now there is only a wgpu-utils that doesn't provide any header. This would provide headers to use for any other application. Note: There is also another implementation (google dawn) of the standard with an open package request issue. Metadata homepage , source license: mit + apache 2 platforms: request for linux, but it should work for any other OS Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks!!!
Change:
runHook postInstall ''; <ins> passthru.tests = { smoke-test = nixosTests.limesurvey; }; </ins> meta = with stdenv.lib; { description = "Open source survey application"; license = licenses.gpl2;

Discussion:
, CVSSv3=9.8 (nixos-20.03, nixos-unstable) CVSSv3=8.8 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.5 (nixos-20.03, nixos-unstable) CVSSv3=7.2 (nixos-20.03, nixos-unstable) CVSSv3=7.2 (nixos-20.03, nixos-unstable) CVSSv3=6.1 (nixos-20.03, nixos-unstable) CVSSv3=6.1 (nixos-20.03, nixos-unstable) CVSSv3=6.1 (nixos-20.03, nixos-unstable) CVSSv3=5.4 (nixos-20.03, nixos-unstable) CVSSv3=5.3 (nixos-20.03, nixos-unstable) CVSSv3=5.3 (nixos-20.03, nixos-unstable) CVSSv3=5.3 (nixos-20.03, nixos-unstable) CVSSv3=5.3 (nixos-20.03, nixos-unstable) CVSSv3=4.3 (nixos-20.03, nixos-unstable) CVSSv3=2.7 (nixos-20.03, nixos-unstable) CVSSv3=2.7 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc
Change:
makeWrapperArgs = [ "--prefix" "PATH" ":" (lib.makeBinPath bins) <ins> "${gappsWrapperArgs[@]}" </ins> ]; <ins> dontWrapGApps = true; </ins> outputs = [ "out" "man" ]; postBuild = '' make -C man

Discussion:
it's impossible to use due to an import error: Steps to reproduce the behavior: to run eg ratbagctl "shows something". (i.e. current mouse hardware/mapping etc.) (no gui, cli only) I (may) need because it has infos/options that are not yet fully implemented in Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

When trying to launch whipper it instead fails with the following trace: Steps to reproduce the behavior: or any equivalent way of running the whipper program Clearly, I expect the program to execute without an error. I bisected the error and the bug was introduced in which bumped . <!-- 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]:
Note: Adding to double-wraps all executables, but allows to run successfully.
Also no double-wrapping.

As title says, openrazer-daemon no longer work after update. Steps to reproduce the behavior: system -daemon fail to start. Openrazer-daemon start on boot. If applicable, add screenshots to help explain your problem. Manually calling openrazer-daemon -Fv print me this: <!-- 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]:
overlay fix for anyone who have this issue.
This overlay fix worked for me, thank you!
Change:
buildPythonPackage rec { pname = "sockjs-tornado"; <del> version = "1.0.5"; </del> <ins> version = "1.0.6"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "4c4bcf33c8a238bbab37d01da769bcf89e74ef6019bfa76ddbcb4d682d47187e"; </del> <ins> sha256 = "ec12b0c37723b0aac56610fb9b6aa68390720d0c9c2a10461df030c3a1d9af95"; </ins> }; propagatedBuildInputs = [ tornado ];

Discussion:
Ran . For some reason there are pylint tests running for ~8 minutes that eventually end up in a failure. <details<summaryPyLint test failures</summary</detailson pylint (indirectly?); running for ~10 minutes as part of package installation process.
This will need to be backported to 18.09 as the latest version released by Hydra is broken too
The tests still fails even after the above patch applied. <details<summaryHere is the log</summary</detailsHere is the patch I used: Edit: the original patch is working on the python-unstable branch so I guess it's OK
I pushed a fix to the branch: . The fix for is currently in the branch: .
Change:
"-DQT_FEATURE_journald=${if systemdSupport then "ON" else "OFF"}" "-DQT_FEATURE_vulkan=ON" ] ++ lib.optionals stdenv.isDarwin [ <del> # build as a set of dynamic libraries "-DFEATURE_framework=OFF" </del> <ins> # error: 'path' is unavailable: introduced in macOS 10.15 "-DQT_FEATURE_cxx17_filesystem=OFF" </ins> ]; NIX_LDFLAGS = toString (lib.optionals stdenv.isDarwin [

Discussion:
Steps to reproduce the behavior: The regression is due to , which forgot to maintain the guard on darwin. While it is straightforward to fix the aarch64-darwin build, it isn't enough for x86_64-darwin due 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.
Change:
stdenv.mkDerivation rec { pname = "peazip"; <del> version = "9.6.0"; </del> <ins> version = "9.7.1"; </ins> src = fetchFromGitHub { owner = "peazip"; repo = pname; rev = version; <del> hash = "sha256-75EkVRx6bX1ZZzeNSR7IvKNjTA5NvzFzUJdORiAVHBo="; </del> <ins> hash = "sha256-HxRpoT+O9nWL4FzB6CjJ0DqnZALaaYtXGb82GkgF2JA="; </ins> }; sourceRoot = "${src.name}/peazip-sources"; <ins> postPatch = '' # set it to use compression programs from $PATH substituteInPlace dev/peach.pas --replace "  HSYSBIN       = 0;" "  HSYSBIN       = 2;" ''; </ins> nativeBuildInputs = [ wrapQtAppsHook lazarus

Discussion:
Steps to reproduce the behavior: <!-- 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:
if grep -q workspace "$out/Cargo.toml"; then chmod u+w "$out/Cargo.toml" <del> ${replaceWorkspaceValues} "$out/Cargo.toml" "${tree}/Cargo.toml" </del> <ins> ${replaceWorkspaceValues} "$out/Cargo.toml" "$(${cargo}/bin/cargo metadata --format-version 1 --no-deps --manifest-path $crateCargoTOML | ${jq}/bin/jq -r .workspace_root)/Cargo.toml" </ins> fi # Cargo is happy with empty metadata.

Discussion:
rustPlatform doesn't support all workspaces features that Iced-rs requires. Specifically, I believe it's this commit (but I'm not entirely sure if that is the problem) that the tooling doesn't support: Steps to reproduce the behavior: ` That the build executes successfully. ! Console output: <!-- 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]:
Fix is in
Change:
feedparser = callPackage ../development/python-modules/feedparser/5.nix { }; <ins> filelock =  callPackage ../development/python-modules/filelock/3.2.nix { }; </ins> flask = callPackage ../development/python-modules/flask/1.nix { }; flask_ldap_login = callPackage ../development/python-modules/flask-ldap-login { };

Discussion:
For me, at commit (latest release) and at commit (latest in the branch), does not build anymore, due some of its dependencies having no Python 2 support anymore. As far as I can see, dropped Python 2 support since release 3.3.0 (nixpkgs commit ) and later this has been enforced within nixpkgs at commit . And is an indirect dependency of . Steps to reproduce the behavior: up a simple nixops-shell that pins nixpkgs to a certain version by placing the following files in a directory: in the current directory. Nixops builds fine and a nix-shell will be entered Backtrace: nixops: filelock: Please run and paste the result. Maintainer information: