jiebi/CodeConvo huggingface dataset:
Code change:
zlib ]; <ins> cmakeFlags = [ "-DGVM_RUN_DIR=$out/run/gvm" ]; </ins> meta = with lib; { description = "Libraries module for the Greenbone Vulnerability Management Solution"; homepage = "https://github.com/greenbone/gvm-libs";

Related discussion:
text: <!-- 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 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: gvm-libs <!-- The current version can be found easily with the same process than 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: 21.4.2 desired version: 21.4.3 <!-- 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.
Code change:
"-DLLVM_TARGETS_TO_BUILD="AMDGPU;X86"" ]; <del> # The comgr build tends to link against the static LLVM libraries # *and* the dynamic library. Linking against both causes errors # about command line options being registered twice. This patch # removes the static library linking. patchPhase = '' sed -e '/^llvm_map_components_to_libnames/,/[[:space:]]*Symbolize)/d'  -i CMakeLists.txt ''; </del> passthru.updateScript = writeScript "update.sh" '' #!/usr/bin/env nix-shell #!nix-shell -i bash -p curl jq common-updater-scripts

Related discussion:
text: Blender 2.93.5 Hallo When I start Blender now and set under “Render Properties” → “Cycles” Blender crashes completely. Also when I go to “Edit” → “Preferences” → “System” Blender crashes immediately with this Error: What does that tell me now? My GPU configuration in the clinfo: nix run -c nix-info -m:
I think this might be the same issue as described in
Code change:
"-DLLVM_TARGETS_TO_BUILD="AMDGPU;X86"" ]; <del> # The comgr build tends to link against the static LLVM libraries # *and* the dynamic library. Linking against both causes errors # about command line options being registered twice. This patch # removes the static library linking. patchPhase = '' sed -e '/^llvm_map_components_to_libnames/,/[[:space:]]*Symbolize)/d'  -i CMakeLists.txt ''; </del> passthru.updateScript = writeScript "update.sh" '' #!/usr/bin/env nix-shell #!nix-shell -i bash -p curl jq common-updater-scripts

Related discussion:
text: Describe the bug Blender segfaults when an OpenCL render is attempted. To Reproduce Steps to reproduce the behavior: Properties (right panel) Select Cycles, change device to GPU Compute Expected behavior It should render. Additional context May be related to and Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information: Blender gdb backtrace: I'm using a Radeon VII with: gives me:
cc
This seems like an upstream issue. The question is which upstream? Does the crash also occur with e.g. the Intel OpenCL runtime?
FWIW, I also see the segfault on an rx580 following the repro instructions. It does like others have Blender working with ROCm OpenCL, so the crash may well be due to our packaging. did such a nice job cleaning up our LLVM derivations that there's much less room for funny business now than with previous releases. I see that we have a option we could give LLVM which might reveal a bit more information?
I can also reproduce the problem on a RX580. Here somebody has the same issue, with a plausible explanation: The conclusion there is that it occurs when two different LLVM versions are used in a process. Which would be the case here, since Blender uses OpenGL. Currently our Mesa is still on LLVM 9, whereas ROCm uses LLVM 11.
Yep, this is probably the issue. If I compile the derivation with a built against , I don't get the segfault. I am not sure yet what the solution is, since we cannot always update the LLVM version that Mesa uses to that of ROCm. I wonder how this is dealt with with ROCm on other distributions. Do they override the system Mesa?
I guess I should have turned up that link first given my prior involvement! Could we substitute a at runtime instead? Perhaps via ICD, or , or even ?
There is , which we could use to override system package. I guess if it works, we could add a module along the lines of the support, which would use as the OpenGL package and could even add the ICD definition to .
Code change:
"-DLLVM_TARGETS_TO_BUILD="AMDGPU;X86"" ]; <del> # The comgr build tends to link against the static LLVM libraries # *and* the dynamic library. Linking against both causes errors # about command line options being registered twice. This patch # removes the static library linking. patchPhase = '' sed -e '/^llvm_map_components_to_libnames/,/[[:space:]]*Symbolize)/d'  -i CMakeLists.txt ''; </del> passthru.updateScript = writeScript "update.sh" '' #!/usr/bin/env nix-shell #!nix-shell -i bash -p curl jq common-updater-scripts

Related discussion:
text: But we should probably first test how well building mesa against the LLVM fork works. At least it builds ;). I might have some time to look at this after work.
If you have a chance, could you elaborate on how you did this in nixos?: I understand that it's not the permanent fix, but I'm quite curious to try it.
I modified nixpkgs in-place, but you could do something like: And then: A more proper solution would be to switch to a -built Mesa for . I do have a branch for this: or the two commits: But I ran into another issue in Blender, and I didn't have time to investigate. The system (including GNOME, etc.) worked fine with Mesa built with llvmPackages_rocm.
Sorry. I misremember. I may have rebuilt my system with Which should be equivalent to having an overlay But I am a bit nervous about switching Mesa to a vendor-forked (IIRC prerelease) of LLVM. We should just document this incompatibility for 20.09 and then perhaps land something like the proposed branch/module in master/21.03. But that definitely requires more testing.
i tried your amdgpu-rocm thing but now blender crashes with this error when opening user preferences: is this the error you mentioned you didn't have time to debug?
That's the one. I am afraid though that I can't help with any further debugging. I had to replace the RX580 in the machine I was testing on by an NVIDIA card, because there were too many issues with training machine learning models on the RX580 :confused: .
this seems very similar to and replies there would seem to indicate that it's still some LLVM incompatibility, but i'm not sure what is incompatible here... is it blender itself?
I think the core problem is that both OpenGL and OpenCL (through winding paths) each load their own instances of LLVM into the process, and those instances of LLVM somehow end up sharing some global data, with usually disastrous results.
It seems that upstream now explicitly states that ROCm is only for headless deployments: Given the risks of compiling Mesa against a vendor fork (we get to fix any bugs), I think that we should just document this in the AMD -OpenCL section of the manual and leave it at that. Do you agree ?
Code change:
"-DLLVM_TARGETS_TO_BUILD="AMDGPU;X86"" ]; <del> # The comgr build tends to link against the static LLVM libraries # *and* the dynamic library. Linking against both causes errors # about command line options being registered twice. This patch # removes the static library linking. patchPhase = '' sed -e '/^llvm_map_components_to_libnames/,/[[:space:]]*Symbolize)/d'  -i CMakeLists.txt ''; </del> passthru.updateScript = writeScript "update.sh" '' #!/usr/bin/env nix-shell #!nix-shell -i bash -p curl jq common-updater-scripts

Related discussion:
text: Given this and the lack of RDNA support, I guess the future of OpenCL for GUI apps is with Mesa's Clover.
I do agree, yes. An AMD employee has been trying to walk things back, but who knows. It doesn’t make sense that they just switched their consumer driver to use ROCm for OpenCL if they don’t have a vision of getting in sync with Mesa, but that’s clearly their row to hoe.
I'm amazed AMD has any foot left to shoot at.
I marked this as stale due to inactivity. &rarr;
Still important, though only in general (OpenCL in GUI apps with AMD GPUs), because .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I think I finally figured out a workaround! Disabling for seems to work. I did it with the following patch to nixpkgs, but it should be possible to do it with an overlay too: After a lot of building, Blender seems happy again :) !
If this works, it is incredible. How would I do it as an overlay?
I think this should do it. It's ugly and there might be a better way but it should at least make it easy to test if it works for you. I'm still trying to figure out if there's a simpler fix (for example, overriding just ), but haven't been able to figure it out yet.
It works for me. I suggest you make a PR with this change to Nixpkgs. It may seem a bit ad-hoc, but otherwise it is not possible for a process to have both OpenGL and ROCm OpenCL loaded simultaneously, which seems like a pretty common use case.
Now that I know it works for other people I'll try to make a PR in the next day or two, yeah :)
Code change:
substituteInPlace bin/mangohud.in  --subst-var-by libraryPath ${lib.makeSearchPath "lib/mangohud" ([ (placeholder "out") <del> ] ++ lib.optionals (stdenv.hostPlatform.system == "x86_64-linux") [ </del> <ins> ] ++ lib.optionals lowerBitnessSupport [ </ins> mangohud32 ])}  --subst-var-by dataDir ${placeholder "out"}/share

Related discussion:
text: Mangohud no longer appears on gnome/wayland when opening a game. "rev": "", (works) "rev": "", (doesn't) Steps to reproduce the behavior: a game on gnome/wayland doesn't appear even when enabled (worked in previous revision of nixpkgs above) ... Mangohud shows system stats Please run and paste the result.
I have the same problem too. I'm using Hyprland btw.
Oh weird. I'll try looking into this. The only thing that really sticks out to me in the diff is possibly ? - but it seems unlikely. I'll do a git bisect to try to narrow it down better.
If it helps you narrow down, here's my repo with the exact commit where mangohud stopped working. If I revert back to previous commit mangohud starts working again:
I bisected it, it's cc
mangohud uses its own internal copy of vulkan-headers: So it's probably the loader? If it is though, it might be tricky to bisect...
So, what are we going to do? Especially w.r.t. 23.05 being around the door. I don't think we should ship a broken mangohud in 23.05. Honestly, I think should have probably not made it to master before branch-off. (Eventhough it was technically merged a few dasy before breaking changes were restricted.)
I'll try to reproduce locally and see if I can bisect vulkan-loader.
cc because of
We could also try updating the headers externally; Mangohud's are really quite old. They use this weird meson wrap thingy rather than letting the distro provide it and it too is very out of date. Also, this is the error we're getting: (This is on 64-bit-only Mangohud.)
It breaks when built with newer headers.
Oh sorry, forgot to get back to this! Maybe we need to switch back to using the system headers?
I'm actually pretty sure it's which we probably don't want to revert, but we may need to look into layer ordering?
oh no - yeah i think you're right, i think the duplicate behaviour was specifically to support multi-arch layers (from what I remember).
Code change:
substituteInPlace bin/mangohud.in  --subst-var-by libraryPath ${lib.makeSearchPath "lib/mangohud" ([ (placeholder "out") <del> ] ++ lib.optionals (stdenv.hostPlatform.system == "x86_64-linux") [ </del> <ins> ] ++ lib.optionals lowerBitnessSupport [ </ins> mangohud32 ])}  --subst-var-by dataDir ${placeholder "out"}/share

Related discussion:
text: If it's just an issue of duplicate layers, perhaps we could add 32 and 64 suffixes to the layer names. obs-vkcapture does that too.
I gave up o pursuing this, as seen in It works, but for this case here, it's probably better to bring attention upstream. Cc
Having only the 64-bit mangohud json in the implicit layer dir works! Going to try giving the 32-bit layer a different name now.
This is also going to affect vkbasalt too then - I haven't tried yet though - I'll take a look at fixing that too!
Speaking of, any reason you gave up on that? I personally really liked the good idea.
Different suffixes work! PR incoming.
It needed a proper rebase+bump to v1.3.250, and I couldn't figure out how to really take a good benefit from it.
Hm, I'll definitely try to pick it up after branch-off then.
Peculiarly, obs-vkcapture seem to do this for some time already: from gamescope might need this fix too.
Code change:
{ lib, stdenv, callPackage, fetchFromGitHub, autoreconfHook, pkg-config , CoreFoundation, IOKit, libossp_uuid <del> , curl, libcap,  libuuid, lm_sensors, zlib </del> , nixosTests <ins> , curl, libcap, libuuid, lm_sensors, zlib </ins> , withCups ? false, cups , withDBengine ? true, libuv, lz4, judy , withIpmi ? (!stdenv.isDarwin), freeipmi , withNetfilter ? (!stdenv.isDarwin), libmnl, libnetfilter_acct <ins> , withCloud ? (!stdenv.isDarwin), json_c </ins> , withSsl ? true, openssl , withDebug ? false <del> , fetchpatch </del> }: with lib;

Related discussion:
text: Project description Netdata agent plugin Metadata homepage URL: source URL: license: GPL 3.0 platforms: unix, linux, darwin We already do have netdata, however it seems to be built without support for the cloud agent that allows it to stream to the cloud or other netdata servers.
I have a local checkout with some edits that allow me to build netdata with cloud support. Unfortunately they also require a change in the libwebsockets build expression. Should I open a PR to integrate my changes into nixpkgs?
A PR would be great! I'm not a maintainer, but if they decide it's out of scope for nixpkgs, perhaps one on NUR might work - I'd try for a PR here first though
Great, I think having a configuration option that is per default would make sense. Maybe ?
Yeah, that seems to fall in line with the various flags present in other packages
I marked this as stale due to inactivity. &rarr;
Upstream has incorporated some of the suggestions in this thread, I intend to pick up on it again soon
what would be needed to make this work? Perhaps I can help?
The newest major release of Netdata (1.30.0) includes a cloud link implementation without the need for vendored dependencies. Unfortunately, it is not currently in a reliable state because of a bug in the custom HTTPS implementation. The has already been merged into Netdata master and will be included in the next release. I plan to make a PR that enables cloud support as soon as that release is available.
v1.31.0 dropped 12 minutes ago :) Anything I can do to help?
Thanks, I've already gotten a notification for that. Planning to make a PR when I get off work today. When my PR is done, it would be helpful if you could test my changes on your machines.
Just FYI, I have opened the PR that enables cloud support a few days ago. If you are still interested it would be greatly appreciated if you could test if everything works for you and maybe drop a comment.
Sorry, missed this but the pr looks good! I propose we backport this to stable?
Code change:
<ins> { stdenv, config, lib, fetchurl, cmake, doxygen, extra-cmake-modules, wrapGAppsHook # For `digitaglinktree` , perl, sqlite , libsForQt5 , bison , boost , eigen , exiv2 , ffmpeg_4 , flex , graphviz , imagemagick , lcms2 , lensfun , libgphoto2 , liblqr1 , libusb1 , libheif , libGL , libGLU , opencv , pcre , x265 , jasper # For panorama and focus stacking , enblend-enfuse , hugin , gnumake , cudaSupport ? config.cudaSupport , cudaPackages ? {} }: stdenv.mkDerivation rec { pname   = "digikam"; version = "8.2.0"; src = fetchurl { url = "mirror://kde/stable/${pname}/${version}/digiKam-${version}.tar.xz"; hash = "sha256-L3/LVZsSPtnsrlpa729FYO7l9JIG2dF0beyatsj7OL8="; }; strictDeps = true; depsBuildBuild = [ cmake ]; nativeBuildInputs = [ cmake doxygen extra-cmake-modules libsForQt5.kdoctools libsForQt5.wrapQtAppsHook wrapGAppsHook ] ++ lib.optionals cudaSupport (with cudaPackages; [ cuda_nvcc ]); buildInputs = [ bison boost eigen exiv2 ffmpeg_4 flex graphviz imagemagick lcms2 lensfun libgphoto2 libheif liblqr1 libusb1 libGL libGLU opencv pcre x265 jasper ] ++ (with libsForQt5; [ libkipi libksane libqtav qtbase qtxmlpatterns qtsvg qtwebengine qtnetworkauth akonadi-contacts kcalendarcore kconfigwidgets kcoreaddons kfilemetadata knotifications knotifyconfig ktextwidgets kwidgetsaddons kxmlgui breeze-icons marble oxygen threadweaver ]) ++ lib.optionals cudaSupport (with cudaPackages; [ cuda_cudart ]); cmakeFlags = [ "-DENABLE_MYSQLSUPPORT=1" "-DENABLE_INTERNALMYSQL=1" "-DENABLE_MEDIAPLAYER=1" "-DENABLE_QWEBENGINE=on" "-DENABLE_APPSTYLES=on" "-DCMAKE_CXX_FLAGS=-I${libsForQt5.libksane}/include/KF5" # fix `#include <ksane_version.h>` ]; dontWrapGApps = true; preFixup = '' qtWrapperArgs+=("''${gappsWrapperArgs[@]}") qtWrapperArgs+=(--prefix PATH : ${lib.makeBinPath [ gnumake hugin enblend-enfuse ]}) qtWrapperArgs+=(--suffix DK_PLUGIN_PATH : ${placeholder "out"}/${libsForQt5.qtbase.qtPluginPrefix}/${pname}) substituteInPlace $out/bin/digitaglinktree  --replace "/usr/bin/perl" "${perl}/bin/perl"  --replace "/usr/bin/sqlite3" "${sqlite}/bin/sqlite3" ''; meta = with lib; { description = "Photo Management Program"; license = licenses.gpl2; homepage = "https://www.digikam.org"; maintainers = with maintainers; [ spacefault ]; platforms = platforms.linux; mainProgram = "digikam"; }; } </ins>

Related discussion:
text: Package name: digikam Latest released version: 8.2.0 Current version on the unstable channel: 8.1.0 Current version on the stable/release channel: 8.1.0 Notify maintainers Changelog: Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
, glfw , xorg , gamescopeSupport ? true # build mangoapp and mangohudctl <ins> , lowerBitnessSupport ? stdenv.hostPlatform.is64bit # Support 32 bit on 64bit </ins> , nix-update-script }:

Related discussion:
text: Mangohud no longer appears on gnome/wayland when opening a game. "rev": "", (works) "rev": "", (doesn't) Steps to reproduce the behavior: a game on gnome/wayland doesn't appear even when enabled (worked in previous revision of nixpkgs above) ... Mangohud shows system stats Please run and paste the result.
I have the same problem too. I'm using Hyprland btw.
Oh weird. I'll try looking into this. The only thing that really sticks out to me in the diff is possibly ? - but it seems unlikely. I'll do a git bisect to try to narrow it down better.
If it helps you narrow down, here's my repo with the exact commit where mangohud stopped working. If I revert back to previous commit mangohud starts working again:
I bisected it, it's cc
mangohud uses its own internal copy of vulkan-headers: So it's probably the loader? If it is though, it might be tricky to bisect...
So, what are we going to do? Especially w.r.t. 23.05 being around the door. I don't think we should ship a broken mangohud in 23.05. Honestly, I think should have probably not made it to master before branch-off. (Eventhough it was technically merged a few dasy before breaking changes were restricted.)
I'll try to reproduce locally and see if I can bisect vulkan-loader.
cc because of
We could also try updating the headers externally; Mangohud's are really quite old. They use this weird meson wrap thingy rather than letting the distro provide it and it too is very out of date. Also, this is the error we're getting: (This is on 64-bit-only Mangohud.)
It breaks when built with newer headers.
Oh sorry, forgot to get back to this! Maybe we need to switch back to using the system headers?
I'm actually pretty sure it's which we probably don't want to revert, but we may need to look into layer ordering?
oh no - yeah i think you're right, i think the duplicate behaviour was specifically to support multi-arch layers (from what I remember).
Code change:
, glfw , xorg , gamescopeSupport ? true # build mangoapp and mangohudctl <ins> , lowerBitnessSupport ? stdenv.hostPlatform.is64bit # Support 32 bit on 64bit </ins> , nix-update-script }:

Related discussion:
text: If it's just an issue of duplicate layers, perhaps we could add 32 and 64 suffixes to the layer names. obs-vkcapture does that too.
I gave up o pursuing this, as seen in It works, but for this case here, it's probably better to bring attention upstream. Cc
Having only the 64-bit mangohud json in the implicit layer dir works! Going to try giving the 32-bit layer a different name now.
This is also going to affect vkbasalt too then - I haven't tried yet though - I'll take a look at fixing that too!
Speaking of, any reason you gave up on that? I personally really liked the good idea.
Different suffixes work! PR incoming.
It needed a proper rebase+bump to v1.3.250, and I couldn't figure out how to really take a good benefit from it.
Hm, I'll definitely try to pick it up after branch-off then.
Peculiarly, obs-vkcapture seem to do this for some time already: from gamescope might need this fix too.