jiebi/CodeConvo huggingface dataset:
Change:
_qt5_LinguistTools_check_file_exists(${imported_location}) set_target_properties(Qt5::lconvert PROPERTIES <ins> --- a/src/macdeployqt/shared/shared.cpp +++ b/src/macdeployqt/shared/shared.cpp @@ -1241,6 +1241,12 @@ bool deployQmlImports(const QString &appBundlePath, DeploymentInfo deploymentInf if (!QFile(qmlImportScannerPath).exists()) qmlImportScannerPath = QCoreApplication::applicationDirPath() + "/qmlimportscanner"; +#ifdef NIXPKGS_QMLIMPORTSCANNER +    // Fallback: Nixpkgs hardcoded path +    if (!QFile(qmlImportScannerPath).exists()) +        qmlImportScannerPath = NIXPKGS_QMLIMPORTSCANNER; +#endif + // Verify that we found a qmlimportscanner binary if (!QFile(qmlImportScannerPath).exists()) { LogError() << "qmlimportscanner not found at" << qmlImportScannerPath; </ins>

Discussion:
We are currently stuck on qt 5.11 on darwin/macOS. To get things consistent, this should update to qt 5.12 (or even 5.13) soon. Please run and paste the results.
If qt512 builds on darwin we should change the default version:
is currently broken:
Fixed in

When running the provided by the package, it complains about not finding the tool, which is provided by . I have not found a suitable workaround, since it seems like the location of the scanner is hardcoded inside Invoke on a project using Qt. How to use this tool is explained here: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(raskolnikov): nixpkgs:
The error is as follows:
Hi I tried withyour latestchanges from . The fact that Qt 5.12 now works on Darwin again is great news! However, this issue seems to not be resolved. Now the does not bail out inmmediately as it did before. It does indeed do something for a while, but then later I get: Maybe there is some other part of the code where it is missing the path correction? Thanks a lot!
My bad, I was actually using the old one by mistake... I am getting new errors though: I will investigate...
I think I found the issue. The problem is this line: is returning , which is incorrect. I think lines 1258-1260 can be discarded altogether since without the tool is still correctly using , which is a better way of passing the import paths, since inside Nix we actually need multiple import paths anyways due to the modularized Qt installation. Would you be happy to extend the patch with such a modification?
Ok... I have further investigated and I was wrong... One must indeed pass to to really make it work. One can indeed pass multiple times, and probably we shall do it for every entry in . Probably this can be patched... but it seems like we are getting into non trivial patching territory...
Thanks Mathew for reopening the issue. I opened a corresponding issue on Qt:
I marked this as stale due to inactivity. &rarr;
Actually this still stands and it'd be nice to have it fixed some day. There are other issues that are blocking me on Mac these days though, like .
I marked this as stale due to inactivity. &rarr;
Change:
<del> { lib, fetchFromGitHub, python3, glib, cairo, pango, pkg-config, libxcb, xcbutilcursor }: </del> <ins> { lib, fetchFromGitHub, python3, mypy, glib, cairo, pango, pkg-config, libxcb, xcbutilcursor }: </ins> let enabled-xcffib = cairocffi-xcffib: cairocffi-xcffib.override {

Discussion:
A clear and concise description of what the bug is. Steps to reproduce the behavior: Note: I'm on the channel. NixOS config, add to . into qtile. . I expected qtile to check the configuration file. If applicable, add screenshots to help explain your problem. Maintainer information:
Do you mind trying ? Should expose mypy commands to qtile
Change:
in stdenv.mkDerivation rec { pname = "neovim-unwrapped"; <del> version = "0.4.4"; </del> <ins> version = "0.5.0"; </ins> src = fetchFromGitHub { owner = "neovim"; repo = "neovim"; rev = "v${version}"; <del> sha256 = "11zyj6jvkwas3n6w1ckj3pk6jf81z1g7ngg4smmwm7c27y2a6f2m"; </del> <ins> sha256 = "0lgbf90sbachdag1zm9pmnlbn35964l3khs27qy4462qzpqyi9fi"; </ins> }; patches = [

Discussion:
Describe the bug I have an overlay to install neovim from a recent commit. When you use that overlay on a intel macbook neovim is compiled against luajit 2.1.0-beta3 while the same derivation on an M1 macbook compiles against Lua 5.1. I tried checking why that might be given it's the same exact overlay and luajit seems to compile just fine on aarch64 but I am afraid my nix skills weren't good enough. To Reproduce neovim with the following overlay: neovim the command On intel you will see: While on arm: Main issue is that lots of nvim plugins require luajit and don't work with lua 5.1 Expected behavior neovim should be compiled against luajit. Screenshots N/A Additional context Add any other context about the problem here. Notify maintainers Metadata Intel: Arm: Maintainer information:
This is alredy done in
Oh, thanks for the quick response and for the great work. Closing this :)
Reopening, since this will again be the case once is merged. By some reason builds with luajit on aarch64 still fail and I do not know why. As explained in , simply updating luajit does not help.
fixed in
switched back to using Lua 5.1 due to I think this issue should be reopened. Especially due to from the OP Also see my comment above
I've been messing around with this for a few days without much success, but I do think that compiling with openresty-luajit does work (at least, luarocks builds successfully and the error in question with goes away). I am utterly lost in the maze of Nix abstractions though and don't know the best way to do this. I've tried using overlays to set LuaJIT to be the openresty version which seems to half work, but when I try and build neovim it's still using the version of luarocks built with LuaJIT 2.1. Can someone who knows their way around Nix a little better take a deeper look into this? EDIT: I got it to work! I'm using the following overlay: This issue helped me figure out why my overriden value of wasn't applying to the packages.

I had to add to the override function.
Maybe make a pr for that so nixpkgs will use this version of luajit by default on macOS aarch64.
Done
merged.
This problem appear again, I used on ubuntu22.04 aarch64 (m1 Docker), and got same error with the NVIM 0.7.2: And my luaSnip plugin can not work. (It's ok under intel x64)
I'm also hitting this issue again on aarch64 (m1 Docker) on ubuntu 22.04 and 20.04
Same here, exact same environment and output as
I am also seeing the same error in ubuntu 22.04 VM running on M1 MAC. This is based on aarch64. Anyone know how to fix the issue?
Change:
zlog = callPackage ../development/libraries/zlog { }; <del> zeromq3 = callPackage ../development/libraries/zeromq/3.x.nix {}; </del> zeromq4 = callPackage ../development/libraries/zeromq/4.x.nix {}; zeromq = zeromq4;

Discussion:
, (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
According to this comment , should not be affected. Nontheless, this is a very old version and there are only two packages depends on it: rzmq (apparently supports 4.x but is broken since 2016) jzmq (support 3.x and looks unmaintained) jzmq is only needed by apache stom but the dependecy as since been dropped: see can you update apache storm so we can get rid of jzmq?
Change:
"-DCUDA_FAST_MATH=ON" "-DCUDA_HOST_COMPILER=${cudatoolkit.cc}/bin/cc" "-DCUDA_NVCC_FLAGS=--expt-relaxed-constexpr" <ins> "-DNVIDIA_OPTICAL_FLOW_1_0_HEADERS_PATH=${nvidia-optical-flow-sdk}" </ins> ] ++ lib.optionals stdenv.isDarwin [ "-DWITH_OPENCL=OFF" "-DWITH_LAPACK=OFF"

Discussion:
Describe the bug OpenCV 4 fails to build with cuda enabled due to missing NVIDIA optical flow sdk To Reproduce Steps to reproduce the behavior: -build -A opencv4 Expected behavior Either we disable OpenCV 4's option to compile with the NVIDIA optical flow SDK or allow compilation against the NVIDIA optical flow sdk headers. See: I've done some preliminary work towards this on the following branch:
Change:
echom repeat("=", 80) endif let opts = {} <del> let opts.nix_prefetch_git = "${nix-prefetch-scripts}/bin/nix-prefetch-git" let opts.nix_prefetch_hg  = "${nix-prefetch-scripts}/bin/nix-prefetch-hg" </del> <ins> let opts.nix_prefetch_git = "${nix-prefetch-git}/bin/nix-prefetch-git" let opts.nix_prefetch_hg  = "${nix-prefetch-hg}/bin/nix-prefetch-hg" </ins> let opts.cache_file = g:vim_addon_manager.plugin_root_dir.'/cache' let opts.plugin_dictionaries = [] ${lib.concatMapStrings (file: "let opts.plugin_dictionaries += map(readfile("${file}"), 'eval(v:val)')n") namefiles }

Discussion:
It's frustrating to have to build all the version control systems (in master or another development branch without binary caches) when I just need to prefetch git :frowning:
Make the expression modular so you can disable those?
Implementation at:
Change:
{ lib, stdenv, fetchurl, dpkg, makeWrapper, buildFHSUserEnv , gtk3, gdk-pixbuf, cairo, libjpeg_original, glib, pango, libGLU <del> , nvidia_cg_toolkit, zlib, openssl, portaudio </del> <ins> , libGL, nvidia_cg_toolkit, zlib, openssl, libuuid , alsaLib, udev </ins> }: let fullPath = lib.makeLibraryPath [

Discussion:
Describe the bug I cannot run lightworks from 19.09 branch. Running produces . I am using ThinkPad W530 with i7-3740QM. I use the integrated Intel GPU and optionally use optirun to run tasks on the NVIDIA QUADRO 1000M. When I run I get . To Reproduce Steps to reproduce the behavior without optirun: Steps to reproduce the behavior with optirun: to your Expected behavior Lightwork would start up. Metadata Maintainer information:
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
No relevant changes were made to the lightworks package therefore the issue still occurs. I expect to fix this, however it is not merged yet.
Change:
]; meta = { <ins> mainProgram = "iconv"; </ins> platforms = lib.platforms.darwin; }; }

Discussion:
On aarch64-darwin, works fine in a nix shell but errors with . The fix might be as simple as renaming the expected binary (in which case I'd be happy to make a PR): Was hoping to be able to run iconv with . None listed at may be the most recent touch via git blame (sorry, I know you're busy). Please run and paste the result.
Change:
"tests/test_cookies.py" ]; <ins> # cherrypy does not support Python 3.11 doCheck = pythonOlder "3.11"; </ins> meta = { changelog = "https://github.com/jaraco/jaraco.net/blob/${src.rev}/CHANGES.rst"; description = "Networking tools by jaraco";

Discussion:
When attempting to configure the integration I get an error in Home Assistant Steps to reproduce the behavior: to to configure integration from Home Assistant UI Able to configure <!-- 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.
The package does not eval on master right now, because of a dependency being flagged as disabled for python 3.11. Though I'd be surprised if that is your issue. nix-replhome- error: … while evaluating the attribute 'drvPath' at 221| in commonAttrs // { 222| drvPath = assert condition; drv.drvPath; | ^ 223| outPath = assert condition; drv.outPath; … while evaluating the attribute 'drvPath' at 221| in commonAttrs // { 222| drvPath = assert condition; drv.drvPath; | ^ 223| outPath = assert condition; drv.outPath; (stack trace truncated; use '--show-trace' to show the full trace) error: cherrypy-18.8.0 not supported for interpreter python3.11
Regardless, at least makes evaluate.
Change:
stdenv.mkDerivation (rec { <del> name = "gnutls-3.1.3"; </del> <ins> name = "gnutls-3.1.10"; </ins> src = fetchurl { <del> url = "mirror://gnu/gnutls/${name}.tar.xz"; sha256 = "0fff9frz0ycbnppfn0w4a2s9x27k21l4hh9zbax3v7a8cg33dcpw"; </del> <ins> url = "mirror://gnupg/gnutls/v3.1/${name}.tar.xz"; sha256 = "0in6wxlvpv48maawmbg3jysq2rhjqxypgi6kkr173hc8kksp6lsk"; </ins> }; # Note: GMP is a dependency of Nettle, whose public headers include

Discussion:
When i try to rebuild my mobile nixos on the pinephone from latest unstable channel i get this error. This issues is not present at . Steps to reproduce the behavior: Pinephone from image config -rebuild no errors If applicable, add screenshots to help explain your problem. 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. --- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Bisected this to .
I think this is better to fix in mobile-nixos.
Change:
setuptools, wrapGAppsNoGuiHook, notify2, <ins> glib </ins> }: let

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:
stdenv.mkDerivation rec { pname = "alpine"; <del> version = "2.24"; </del> <ins> version = "2.25"; </ins> src = fetchurl { url = "http://alpine.x10host.com/alpine/release/src/${pname}-${version}.tar.xz"; <del> sha256 = "1vxw19nx10y7nx01d9i6gah2f3y5r2idbq56l13bdqi91bx9y6k5"; </del> <ins> sha256 = "0xppxhcbafq9qa1rns5zl0n238gai08xhvcf2as0nx7nh84ib2k5"; </ins> }; buildInputs = [

Discussion:
, CVSSv3=5.9 (nixos-21.05, nixos-unstable) In Alpine through 2.24, untagged responses from an IMAP server are accepted before STARTTLS. Scanned versions: nixos-21.05: ; nixos-unstable: . Cc
Change:
pname = "bcachefs-tools"; version = "1.4.1"; src = fetchFromGitHub { owner = "koverstreet"; repo = "bcachefs-tools";

Discussion:
NixOS on boot loops waiting for devices with wrong names. According to device paths are split by ":", but for some persistent block device names we have ":" in valid paths. The boot is stuck trying to load: Steps to reproduce the behavior: NixOS using /dev/disk/by-path devices boot waiting loop Boot without waiting for nonexistant devices ! Please run and paste the result.
This is a recent phenomenon I've experienced a few times, on bcachefs. I'm not entirely sure why this happens, but since Linux 6.4.8 I believe, I haven't had this issue. There are two reasons why this could happen AFAIK: is messed up between the linux kernel and stage-1. needs to have all the devices loaded before trying to mount multiple. That's the best I have ATM. Current nix-info for reference: system: host os: multi-user?: sandbox: version: channels(mado): channels(root): nixpkgs:
I should also clarify in my case that it was a breaking bug, where I would have to reboot because one of the devices never loaded and would drop me into an error, until it worked.
it seems like you're describing a different issue with bcachefs and multiple devices separated by . This bug, as far as I understand, is about non-bcachefs block device paths that contain incidentally (not as a multi-device delimiter). I'd suggest filing a separate issue for your problem.
(But as the author of the change that introduced that behavior - - I suspect you might want to be involved here regardless :P)
My bad, the usual bad reading comprehension and I didn't look at the paths that were listed closely enough. I would suggest, if possible, using something like instead until this is fixed. As for the fix, while it would break the use-case of colon-separated if it is the aforementioned path.
This should be considered a bug. There are a lot of paths in that have colons in their name (including RAID UUID devices). Requiring users to know that devices with colons in their name are treated special is unreasonable, especially if it's not documented. If bcachefs requires this then I think we need a new configuration option or the stage 1 function needs to be extended so it considers the file system type before setting .

IMO, we should get rid of it for bcachefs (it's only use) and just use the new ` mechanism.
I don't use bcachefs so I don't know what the mechanism is. Is it safe to simply revert your patch to ?
Unfortunately no, because many people's auto-generated configs still use the ':' separator. It's something I think we'll have to do at some point though. I think the better option may be to omit a warning if it's being used (i.e: using bcachefs) until 24.05, backport that to 23.11, and remove it in 24.05.
I would suggest that we change the function to take an optional second argument, the file system type. If that argument is set and it is set to "" then (and only then) do we set . Of course, this only works if the auto-generated configs correctly set the file system type. Can you point me to the commit where you changed the auto-generation process?
Should be fixed in
Change:
#include "pipe/p_compiler.h" #include "pipe/p_state.h" <del> --- ./src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h +++ ./src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h </del> <ins> --- a/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h +++ b/src/amd/vulkan/winsys/amdgpu/radv_amdgpu_winsys.h </ins> @@ -28,6 +28,8 @@ #ifndef RADV_AMDGPU_WINSYS_H #define RADV_AMDGPU_WINSYS_H +#include <sys/types.h> + <del> #include "radv_radeon_winsys.h" #include "ac_gpu_info.h" #include "addrlib/addrinterface.h"<Paste> </del> <ins> #include <amdgpu.h> #include <pthread.h> #include "util/list.h" </ins>

Discussion:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.
Change:
}; in { <del> hbase_1_7 = common { version = "1.7.1"; hash = "sha256-DrH2G79QLT8L0YTTmAGC9pUWU8semSaTOsrsQRCI2rY="; jdk = jdk8_headless; tests.standalone = nixosTests.hbase1; }; </del> hbase_2_4 = common { <del> version = "2.4.11"; hash = "sha256-m0vjUtPaj8czHHh+rQNJJgrFAM744cHd06KE0ut7QeU="; </del> <ins> version = "2.4.15"; hash = "sha256-KJXpfQ91POVd7ZnKQyIX5qzX4JIZqh3Zn2Pz0chW48g="; tests.standalone = nixosTests.hbase_2_4; }; hbase_2_5 = common { version = "2.5.1"; hash = "sha256-ddSa4q43PSJv1W4lzzaXfv4LIThs4n8g8wYufHgsZVE="; </ins> tests.standalone = nixosTests.hbase2; }; hbase_3_0 = common { <del> version = "3.0.0-alpha-2"; hash = "sha256-QPvgO1BeFWvMT5PdUm/SL92ZgvSvYIuJbzolbBTenz4="; </del> <ins> version = "3.0.0-alpha-3"; hash = "sha256-TxuiUHc2pTb9nBth1H2XrDRLla2vqM+e1uBU+yY2/EM="; </ins> tests.standalone = nixosTests.hbase3; }; }

Discussion:
Apache HBase 1.7 EOL was in 2022/08, can we remove it? via
Hey. Thanks for reminding me. I have a WIP PR for this: I'm not sure why I left it as a draft... I'll go over it again and open it if it's ready.
Change:
./services/misc/emby.nix ./services/misc/errbot.nix ./services/misc/etcd.nix <ins> ./services/misc/exhibitor.nix </ins> ./services/misc/felix.nix ./services/misc/folding-at-home.nix ./services/misc/fstrim.nix

Discussion:
We currently have a nice ZooKeper module and package, but apparently all the cool kids run ZK via , which we don't have packaged or any module around. Anyone feel like packaging and/or writing a module for it? cc who have dealt with ZK
I would like to own this. Thank you for bringing this up.
Let's assign it to you then &ndash; informally, as GitHub only allows that for organization members (or some similar condition).
Thanks
is this happening?
Sorry for the delay. Yes I am working on this.
any progress?
FYI, I took a crack at this in