jiebi/CodeConvo huggingface dataset:
Change:
mkdir -pv $out/usr/lib/wechat-uos/license ln -s ${uosLicenseUnzipped}/* $out/usr/lib/wechat-uos/license/ <del> cp -r wechat-uos-old-source/usr/lib/license/libuosdevicea.so $out/usr/lib/wechat-uos/license/ </del> <ins> ln -s ${libuosdevicea}/lib/libuosdevicea.so $out/usr/lib/wechat-uos/license/ </ins> runHook postInstall '';

Discussion:
the package wechat uos is still using OpenSSL 1.1 which is end of life on 2023/09/11, so it is marked as insecure now. not sure if we need to wait for wechat-uos or we can just bump it up in here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
As far as I know, only from depends on OpenSSL 1.1. Seems like we may replace it with to completely remove dependency. I will try to fix that in the next PR when I have free time.
Would it be offensive if I could submit a patch about it now.
Feel free to do so. I would be happy to review your pr :)
Change:
installPhase = '' cp -r . $out <del> wrapProgram $out/slimserver.pl  --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ zlib stdenv.cc.cc.lib ]}"  --prefix PATH : "${lib.makeBinPath ([ lame flac faad2 sox wavpack ] ++ (lib.optional stdenv.isLinux monkeysAudio))}" </del> <ins> wrapProgram $out/slimserver.pl --prefix LD_LIBRARY_PATH : "${libPath}" --prefix PATH : "${binPath}" wrapProgram $out/scanner.pl --prefix LD_LIBRARY_PATH : "${libPath}" --prefix PATH : "${binPath}" </ins> mkdir $out/bin ln -s $out/slimserver.pl $out/bin/slimserver '';

Discussion:
I try to use slimserver with the tidal plugin. Slimserver looks normally (e.g the webui works), but it spams the log with and squeezelite isn't outputting any audio when i try to play something (without any error logs) Steps to reproduce the behavior: and run slimserver the tidal plugin and run squeezelite to play something I expect listening to audio but it just keeps silent. The logspam only starts as soon as i try to play something. But then it never stops even if i disconnect all players. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Which nixos release or branch are you on? Can you try using a radio station or local media as an alternative to the tidal plugin?
I'm on unstable from today. Radio and local media work fine.
I am also encountering this issue with the qobuz plugin. Also I haven't figured out why, but indexing doesn't work for me, but if i try to play a local file (finding it via the file system option) I also get similar errors complaining about not being found etc.
When I went to spin this up I discovered that library importing was failing with the same error. After some troubleshooting another vendored version of this library was found. Cleaning this up and upgrading AudioScan to the slimserver fork resolved library importing, and I verified Qobuz is also playing. and can you test this PR to see if it fixes your issues? Thanks! Feel free to comment or reopen if still having this issue.
i just tested the pr and can confirm that the tidal works fine now. Thank you very much!
Change:
#       { libsOnly = true; }; # } , nvidiaComputeDrivers ? null <ins> , fetchpatch </ins> }: # ArrayFire compiles with 64-bit BLAS, but some tests segfault or throw

Discussion:
Auto-updates for this package seem to fail due to changes to opencl-headers that introduce cmake Seems to me like should fix this issue and no manual intervention will be needed, but I'm not entirely sure. At the moment this package is very outdated and misses bugfixes without which software using this library fails to build with certain compiler flags. I'm not sure who to tag here since the package has no maintainers. this issue seems relevant. Package name: opencl-clhpp Latest released version: 2023.12.14 <!-- Search your package here: --- Current version on the unstable channel: 2.0.15 Current version on the stable/release channel: 2.0.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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Indeed seems like cmake patch has resolved auto-update issue:
Change:
default = null; type = types.uniq (types.nullOr types.string); }; mongoConfig = mkOption { description = "MongoDB integration configuration"; default = null;

Discussion:
Expected output: empty gohai can be found here: This holds for nixpkgs master.
I've submitted to fix this issue. We've worked around it until this is released by adding the derivation to our NixOS configuration repository and adding it to the unit's path, like so: NixOS will merge that option together with the already existing derivations on the unit's path, so it doesn't break the existing configuration. We've been running this change on a dozen or so live-servers and it works fine.
pull request was merged.
The fix is now in 18.03 :)
Change:
wrapNeovimUnstable = callPackage ../applications/editors/neovim/wrapper.nix { }; wrapNeovim = neovim-unwrapped: lib.makeOverridable (neovimUtils.legacyWrapper neovim-unwrapped); neovim-unwrapped = callPackage ../applications/editors/neovim { <del> lua = luajit; </del> <ins> # neovim doesn't build with luajit on aarch64: # ./luarocks init # PANIC: unprotected error in call to Lua API (module 'luarocks.core.hardcoded' not found: #         no field package.preload['luarocks.core.hardcoded'] #         no file '/private/tmp/nix-build-luarocks-3.2.1.drv-0/source/src/luarocks/core/hardcoded.lua' #         no file './luarocks/core/hardcoded.lua' #         no file '/nix/store/3s6c509q9vvq3db87rfi7qa38wzxwz8w-luajit-2.1.0-2021-05-29/share/luajit-2.1.0-beta3/luarocks/core/hardcoded.lua' #         no file '/usr/local/share/lua/5.1/luarocks/core/hardcoded.lua' #         no file '/usr/local/share/lua/5.1/luarocks/core/hardcoded/init.lua' #         no file '/nix/store/3s6c509q9vvq3db87rfi7qa38wzxwz8w-luajit-2.1.0-2021-05-29/share/lua/5.1/luarocks/core/hardcoded.lua' #         no file '/nix/store/3s6c509q9vvq3db87rfi7qa38wzxwz8w-luajit-2.1.0-2021-05-29/share/lua/5.1/luarocks/core/hardcoded/init.lua' #         no file './luarocks/core/hardcoded.so' #         no file '/usr/local/lib/lua/5.1/luarocks/core/hardcoded.so' #         no file '/nix/store/3s6c509q9vvq3db87rfi7qa38wzxwz8w-luajit-2.1.0-2021-05-29/lib/lua/5.1/luarocks/core/hardcoded.so' #         no file '/usr/local/lib/lua/5.1/loadall.so' #         no file './luarocks.so' #         no file '/usr/local/lib/lua/5.1/luarocks.so' #         no file '/nix/store/3s6c509q9vvq3db87rfi7qa38wzxwz8w-luajit-2.1.0-2021-05-29/lib/lua/5.1/luarocks.so' #         no file '/usr/local/lib/lua/5.1/loadall.so') # make: *** [GNUmakefile:57: luarocks] Error 1 # # See https://github.com/NixOS/nixpkgs/issues/129099 # Possibly related: https://github.com/neovim/neovim/issues/7879 lua = if stdenv.isAarch64 then lua5_1 else luajit; </ins> }; neovimUtils = callPackage ../applications/editors/neovim/utils.nix { };

Discussion:
Describe the bug Since made it into nixpkgs-unstable I can't install neovim on an M1 laptop anymore, error is: To Reproduce Steps to reproduce the behavior: an M1 macbook run Expected behavior neovim to successfully install Screenshots N/A Additional context Notify maintainers Metadata Maintainer information:
Is it possible for you to check if reverting fixes the issue?
Yeah, that did the trick. It is weird as I can install luajit with no issue so maybe this is just an issue with the build setup rather than with the lua interpreter?
Refs I will test this on my M1 as well tonight
Sorry, tonight came later than I expected - I encountered the same issue on M1 and filed , which fixes it. Seems that luajit version is not the issue here ( did not work), as was suggested in Guess we should do a bit more digging
Change:
passthru = { inherit executableName; <del> inherit (unwrapped) pname version; # for home-manager module </del> <ins> inherit (finalAttrs.finalPackage) pname version; # for home-manager module </ins> }; meta = meta // {

Discussion:
I want to install vscode-insider with fhs support and I have this in my home-manager config: but when I run , it outputs: It seems that my override attr is ignored. Remove the , it work correctly.
Change:
''; # Theano spews warnings and disabled flags if the compiler isn't named g++ <del> cxx_compiler = wrapped "g++" "$HOME/.theano" </del> <ins> cxx_compiler_name = if stdenv.cc.isGNU then "g++" else if stdenv.cc.isClang then "clang++" else throw "Unknown C++ compiler"; cxx_compiler = wrapped cxx_compiler_name "$HOME/.theano" </ins> (    stdenv.lib.optional cudaSupport libgpuarray_ ++ stdenv.lib.optional cudnnSupport cudnn );

Discussion:
Describe the bug pymc3 does not install on macos. To Reproduce Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I had this issue too. My workaround was to just disable the wrapper: cc
That's built for me thanks - I have yet to try running it.
Thanks for the report and sorry for the delay in the followup. I checked on Linux and it seems to be okay. Unfortunately I don't have a Mac to figure out what is going on there. The error is that it isn't finding in the path in the development environment. I'm guessing then maybe isn't part of the stdenv on mac? Or maybe the mac bash isn't compatible with the builtin I used instead of ? Do you know if this is the case? What do you get if you do
Yes you are correct, darwin stdenv doesn't provide "g++", the C++ compiler is "clang++". The bash should be the same as on linux.
Change:
services.xserver.displayManager.xserverArgs = [ "-ac" <del> "-logverbose" "-verbose" </del> "-terminate" "-logfile" "/var/log/X.${toString cfg.display}.log" "-config ${configFile}"

Discussion:
spams my journal regularly with many Those seems to be caused by on in . Is this flag really necessary? It makes reading logs pretty hard, and my has grown to more than 140Mb in the course of two-or-so days.
Addition: We also might want to drop so it won't spam the logfile nor stderr.
Change:
platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "163an1yv8lasbdmdjsj2a4byq1rljg7vf5z86ip33xpb9l133xmm"; </del> <ins> sha256 = "13pbvmkjriq6myynv4gfismiqa9y7bfbvvrfcv25670l4zyiakhm"; </ins> type = "gem"; }; <del> version = "3.1.0"; </del> <ins> version = "3.3.1"; </ins> }; fusuma-plugin-appmatcher = { dependencies = ["fusuma" "rexml" "ruby-dbus"];

Discussion:
The fusuma program in the package of the same name crashes when trying to run it. The breaking change causing this issue was made somewhere in the last 56 days: That's when I last updated this particular host, after which everything was still working fine. Steps to reproduce the behavior: "fusuma" package to run fusuma I expected fusuma to start running and be available for use. N/A Instead of displaying the expected behavior, the program crashes: In addition, if I clone the repo, then open a and run the cloned project in that nix-shell, that runs successfully unmodified on the same host. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks especially for the celerity of the fix!
Is there supposed to be a delay between this merge and availability updating? I can clearly see this PR is merged, but when I update my system the new version isn't in there.
Yes, see
One month later, I don't see the updated package. How long can this take ?
The update is already on master, but I don't think it's been backported yet. Are you on NixOS 23.11 instead of unstable?
Yes.
Backported in , should take a few days to land.
Many thanks for the commit !
Change:
{ lib , stdenvNoCC , fetchFromGitHub <del> , kdeclarative , plasma-framework , plasma-workspace , gitUpdater </del> <ins> , plasma-desktop , qtsvg , unstableGitUpdater </ins> }: stdenvNoCC.mkDerivation { pname = "whitesur-kde"; <del> version = "unstable-2023-10-06"; </del> <ins> version = "2022-05-01-unstable-2024-08-07"; </ins> src = fetchFromGitHub { owner = "vinceliuice"; repo = "whitesur-kde"; <del> rev = "2b4bcc76168bd8a4a7601188e177fa0ab485cdc8"; hash = "sha256-+Iooj8a7zfLhEWnjLEVoe/ebD9Vew5HZdz0wpWVZxA8="; </del> <ins> rev = "a5c704224069a9e10fce82eec3c4ba482924d7ef"; hash = "sha256-GGrddhmYOp2qm1rHyBnSjQIyw0pU7CNJhxUt6da8ZpQ="; </ins> }; # Propagate sddm theme dependencies to user env otherwise sddm does # not find them. Putting them in buildInputs is not enough. propagatedUserEnvPkgs = [ <del> kdeclarative.bin plasma-framework plasma-workspace </del> <ins> plasma-desktop qtsvg </ins> ]; postPatch = '' <del> patchShebangs install.sh </del> <ins> patchShebangs install.sh sddm/install.sh </ins> substituteInPlace install.sh  <del> --replace '$HOME/.config' $out/share  --replace '$HOME/.local' $out  --replace '"$HOME"/.Xresources' $out/doc/.Xresources </del> <ins> --replace-fail '[ "$UID" -eq "$ROOT_UID" ]' true  --replace-fail /usr $out  --replace-fail '"$HOME"/.Xresources' $out/doc/.Xresources substituteInPlace sddm/install.sh  --replace-fail '[ "$UID" -eq "$ROOT_UID" ]' true  --replace-fail /usr $out  --replace-fail 'REO_DIR="$(cd $(dirname $0) && pwd)"' 'REO_DIR=sddm' </ins> substituteInPlace sddm/*/Main.qml  <del> --replace /usr $out </del> <ins> --replace-fail /usr $out </ins> ''; installPhase = '' runHook preInstall mkdir -p $out/doc name= ./install.sh mkdir -p $out/share/sddm/themes <del> cp -a sddm/WhiteSur $out/share/sddm/themes/ </del> <ins> sddm/install.sh </ins> runHook postInstall ''; <del> passthru.updateScript = gitUpdater { }; </del> <ins> passthru.updateScript = unstableGitUpdater { }; </ins> meta = with lib; { description = "MacOS big sur like theme for KDE Plasma desktop";

Discussion:
When installing the package and rebooting the desktop takes longer to load then usual and then only displays a black screen even without selecting the whitesur theme. Opening applications e.g. via shortcuts still works. I am new to nix so please wirte if further information is needed. Steps to reproduce the behavior: whitesur-kde package in the your nix configuration Desktop works as expected ! My current configuration: <details</summary</details<details</summary</details<details</summary</details<details</summary</detailsjournctl log: <details<summaryjournalctl</summary</details<!-- 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]:
can you review , please?
Change:
, lazarus , xorg , libqt5pas <ins> , runCommand </ins> , _7zz , archiver , brotli

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:
rnv = callPackage ../tools/text/xml/rnv { }; <ins> rosie = callPackage ../tools/text/rosie { }; </ins> rounded-mgenplus = callPackage ../data/fonts/rounded-mgenplus { }; roundup = callPackage ../tools/misc/roundup { };

Discussion:
Project description A supercharged alternative to regular expressions (regex), matching patterns against any input text. Metadata homepage URL: https://rosie- source URL: license: mit platforms: unix PS: this may be relevant:
This is a cool program, I'll have a go at packaging :)
Hmm, this will require upstream changes too, as it doesn't seem that amenable to packaging as is. It'll take a bit longer than I hoped, I'll see if I have some quiet time over the holiday period to work on it. But we might be able to avoid the linked as that is about run-time paths, but we know at compile-time where things go.
But while I do that, you can have a play with (it's a hack of a package, but it seems to work, let me know if things are broken). Just clone that repo, and in the repo root directory do .
I think this can be closed since there is a pull request open for this now.
Add to the pr message so github will close the issue automatically when the pr is merged.
Change:
, stdenv , fetchFromGitHub , appstream-glib <ins> , blueprint-compiler </ins> , desktop-file-utils , gobject-introspection , meson

Discussion:
running from displays a transparent window which is only drawn after 40 seconds (I timed it, it's not an exaggeration). Similarly, clicking the menu button takes about 20s to display the menu. Only the close button is "fast". Steps to reproduce the behavior: 's slow ... it displays fast on the right is the transparent window and my wallpaper. ! I'm not running gnome, but xfce+i3+picom if it's relevant. But as junction eventually works, something is probably not missing. cc system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): nixpkgs:
Opens within a few seconds here with LXQt on a twelve-year old CPU... tested with:
I'm using plasma on unstable and I experience normal app delay. (1-2 seconds). (Maybe one or two iterations old). There is ; however, I do not know how applicable it is. I tried to follow the steps using a shell based on the derivation (plus blueprint-compiler) but I encounter the following error (will try again tomorrow) PS: Also thanks, I didnt realize that I needed to update junction to 1.6 (I'll try to do it soon, .... but its a javascript dependency)
Note: the issue does not happen with the flatpak.
it's actually caused by setting to 1, a workaround to
Change:
gappsWrapperArgs+=(--set GDK_PIXBUF_MODULE_FILE "$GDK_PIXBUF_MODULE_FILE") fi <del> if [ -n "$XDG_ICON_DIRS" ]; then gappsWrapperArgs+=(--prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS") fi </del> if [ -n "$GSETTINGS_SCHEMAS_PATH" ]; then gappsWrapperArgs+=(--prefix XDG_DATA_DIRS : "$GSETTINGS_SCHEMAS_PATH") fi

Discussion:
It seems, inkscape is a build-only dependency of mate-utils, but wrapGAppHook makes it a runtime dependency Steps to reproduce the behavior: mate-utils mate-utils doesn't pull inkscape
In fact appears in the binary wrappers, in the definition of . Not being a runtime dependence, it should not. I suppose this should be fixed in .
By runtime dependency I mean it's installed with binary package
In the derivation it appears in , making it a build dependence. Probably the fact that it is mentioned in the binary wrappers created by has the consequence of turning it into a runtime dependence.
Yeah, I see :( Who is maintainer of wrapGAppsHook though? I wanted initially to mention them in the issue, but unable to find that information
cc
Looking at the output of , it probably gets picked up by puts to inside .
I am not sure why would we even want to add the data directories of icon dependencies into . The app’s own icons should be covered by , and adding icon themes like will not work unless the user also configures the system to use that theme (in which case they should have the theme installed). Or the package contains icons in the fallback () theme – but that should mostly just contain application icons (not something most apps would want to use).
I know Qt has QIcon::setThemeName API, so if gtk has something similar, applications can distribute their own icons in separate packages and then pick up with such API
Sure, but I would not expect that to be common – not even Pantheon does that.
So I would suggest just removing this code: It can cause unintended fallout in cases where it picks up stuff like Vala vapi files but I would expect it to be pretty minor – exists mostly just in app packages, not libraries.
Closing since it sounds like this was fixed by the merge of Happy to reopen if I'm mistaken.
Change:
}; binutils = callPackage ./binutils { <del> bash = bash_2_05; </del> tinycc = tinycc-musl; gnumake = gnumake-musl; gnutar = gnutar-musl; }; bzip2 = callPackage ./bzip2 { <del> bash = bash_2_05; </del> tinycc = tinycc-musl; gnumake = gnumake-musl; gnutar = gnutar-musl;

Discussion:
When built with default Nix options, is 0, meaning auto. The stdenv guesses the "correct" core count: minimal-bootstrap just makes fail. Here the build of for example: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Change:
<del> { lib, stdenv, fetchFromGitHub, makeWrapper, coreutils, findutils, getopt, gnugrep, gnused, sops, vault }: </del> <ins> { lib, stdenv, fetchFromGitHub, makeWrapper, coreutils, findutils, getopt, gnugrep, gnused, sops }: </ins> stdenv.mkDerivation rec { pname = "helm-secrets";

Discussion:
Updating my falke to latest nixpkgs unstable gives an error that vault is non-free. But my package doesn't use or need vault. My package at has: This gives the error: If I comment out the it works. Steps to reproduce the behavior: to use nixpkgs-unstable instead of nixpkgs 23.11 Should build without errors. As above. ` Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
helm-secrets depends on vault
What happened to vault? It use to be open source I thought. Did the license change?
Does helm-secrets really depend on vault? From the it says: Which seems to indicate that it should be able to use any secret manager, not just vault.
the vault license change, which sparked quite the outrage. you ask a question and follow with the answer, that's both rare and impressive ^^'' You can see it here: I suggest you follow the recommendation and accept the new license for vault. If you dont need it, you can remove support for it as well from helm-secrets (but will require some nix skills though you can search the web for plenty of examples)
How about switching the dependency from vault to OpenBAO - would that be possible?
Heh, I didn't realize LF forked Vault too. :popcorn: It's certainly possible, but might have unintended side effects for Nix users. (I realize how annoying that might sound, given your recent experience.) By default, helm-secrets supports and . After a quick glance, it looks like both sops and vals use the Vault Go library, so maybe we don't even need at runtime anyway... I wonder if sops and vals will have to alter their licenses... Edit: It seems the is still .
I've just tried a modified helm-secrets derivation, removing all references to , against a repo that uses helm-secrets (with AWS KMS backend) and it worked fine. I then switched the config to point use a Vault backend, and that also worked. Note that I used to get a token, but assuming exists or the env var is set somehow, it seems doesn't need a binary at runtime at all. So, I suggest we drop the dependency.

might you be able to test It Works on my Machine, and I'm fairly confident, but I'd love some additional verification.
It seems to work OK on my system, so far. Don't have a good test case for vault though. Will think about additional ways to test this.