jiebi/CodeConvo huggingface dataset:
Code change:
if ($copyKernels == 0) { $conf .= $grubStore->search . "n"; } <del> if ($extraInitrd) { $conf .= $extraInitrdPath->search . "n"; } </del> $conf .= "  $extraPerEntryConfign" if $extraPerEntryConfig; $conf .= "  multiboot $xen $xenParamsn" if $xen; $conf .= "  " . ($xen ? "module" : "linux") . " $kernel $kernelParamsn";

Related discussion:
text: Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.
Code change:
"-DSPHINX_WARNINGS_AS_ERRORS=OFF" ]; <del> postPatch = '' </del> <ins> postPatch = lib.optional enableSharedLibraries '' </ins> substitute '${./outputs.patch}' ./outputs.patch --subst-var lib patch -p1 < ./outputs.patch '';

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:
"-DSPHINX_WARNINGS_AS_ERRORS=OFF" ]; <del> postPatch = '' </del> <ins> postPatch = lib.optional enableSharedLibraries '' </ins> substitute '${./outputs.patch}' ./outputs.patch --subst-var lib patch -p1 < ./outputs.patch '';

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:
"-DSPHINX_WARNINGS_AS_ERRORS=OFF" ]; <del> postPatch = '' </del> <ins> postPatch = lib.optional enableSharedLibraries '' </ins> substitute '${./outputs.patch}' ./outputs.patch --subst-var lib patch -p1 < ./outputs.patch '';

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:
"-DSPHINX_WARNINGS_AS_ERRORS=OFF" ]; <del> postPatch = '' </del> <ins> postPatch = lib.optional enableSharedLibraries '' </ins> substitute '${./outputs.patch}' ./outputs.patch --subst-var lib patch -p1 < ./outputs.patch '';

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:
final String gradlewBinaryName = Platform.isWindows ? 'gradlew.bat' : 'gradlew'; final Directory tempDir = Directory.systemTemp.createTempSync('flutter_devicelab_shutdown_gradle.'); -    recursiveCopy(Directory(path.join(flutterDirectory.path, 'bin', 'cache', 'artifacts', 'gradle_wrapper')), tempDir); <del> +    recursiveCopy(Directory(path.join(homeDirPath, '.cache', 'flutter', 'artifacts', 'gradle_wrapper')), tempDir); </del> <ins> +    recursiveCopy(Directory(path.join(globals.fsUtils.homeDirPath, '.cache', 'flutter', 'artifacts', 'gradle_wrapper')), tempDir); </ins> copy(File(path.join(path.join(flutterDirectory.path, 'packages', 'flutter_tools'), 'templates', 'app', 'android.tmpl', 'gradle', 'wrapper', 'gradle-wrapper.properties')), Directory(path.join(tempDir.path, 'gradle', 'wrapper'))); if (!Platform.isWindows) { await exec(

Related discussion:
text: When trying to install , the build fails with: To reproduce, use the following and run it with : I think this happens because of the symlink of the , which seems to be resolved while running the build and in that case the symlink target does not exist. /cc btw: could you please also add support for the latest beta / dev / stable releases?
Hey it's fixed in the latest commit. Can you try it ?
Works fine, thank you very much for the fast fix!
Code change:
''; </programlisting> <del> The main difference is that preceding whitespace is automatically stripped from each line, and that characters like </del> <ins> The main difference is that it strips from each line a number of spaces equal to the minimal indentation of the string as a whole (disregarding the indentation of empty lines), and that characters like </ins> <literal>"</literal> and <literal></literal> are not special (making it more convenient for including things like shell <del> code).</para> </del> <ins> code). See more info about this in the Nix manual <link xlink:href="https://nixos.org/nix/manual/#ssec-values">here</link>.</para> </ins> </listitem> </varlistentry>

Related discussion:
text: I can't figure out which are the problematic lines! 5 and 9 do not seem to be any valid lines considering the error descriptions, or they're the lines in the expanded output(??) - I don't get it. I hope it wasn't something I did here: this /etc/nixos/nixpkgs/ git pull (this was last: ) sudo -i nixos-rebuild switch --fallback System: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: ""
Code change:
buildInputs = optionals stdenv.isDarwin (with darwin; [ cups <ins> # `sw_vers` is used by `src/3rdparty/chromium/build/config/mac/sdk_info.py` # to get some information about the host platform. (writeScriptBin "sw_vers" '' #!${stdenv.shell} while [ $# -gt 0 ]; do case "$1" in -buildVersion) echo "17E199";; *) break ;; esac shift done '') </ins> # For sandbox.h include (runCommand "MacOS_SDK_sandbox.h" {} '' install -Dm444 "${lib.getDev darwin.apple_sdk.sdk}"/include/sandbox.h "$out"/include/sandbox.h

Related discussion:
text: The component of the derivation fails to compile on MacOS. But in two ways, and I can't tell what causes one or the other to trigger. On command: On command: the channel compilation failure Compiles.
It has been broken for a while now for different reasons. Maintaining it for darwin is a lot of work and nobody has stepped up to do that. Also, this is a duplicate of
By the way, what is your use case for ?
We're building a desktop version of mobile application and we need for our in-app browser with Ethereum support.
Code change:
buildInputs = optionals stdenv.isDarwin (with darwin; [ cups <ins> # `sw_vers` is used by `src/3rdparty/chromium/build/config/mac/sdk_info.py` # to get some information about the host platform. (writeScriptBin "sw_vers" '' #!${stdenv.shell} while [ $# -gt 0 ]; do case "$1" in -buildVersion) echo "17E199";; *) break ;; esac shift done '') </ins> # For sandbox.h include (runCommand "MacOS_SDK_sandbox.h" {} '' install -Dm444 "${lib.getDev darwin.apple_sdk.sdk}"/include/sandbox.h "$out"/include/sandbox.h

Related discussion:
text: Full log: Error message: That's the result I get from my macOS remote builder. When I run the build on my desktop Mac, it builds fine and uses the impure SDK from my Catalina install (10.15.1): However, the local build displays this warning repeatedly: I assume this is related to the macOS patches and hopefully gives some clue as to why it's broken.
qtbase builds fine on hydra: qtwebengine fails:
Those links point to the same thing. Anyway, strictly speaking I'm trying to build , but it's failing in .
Can you explain what do you mean? How are you using ?
It's a dependency of . edit: sorry, I see what you mean now. is a dependency of . I was confused by the message from the build saying that QT would be installed in .
Sure, depends on . Realistically, your best bet for now is to just use anki from an old version of nixpkgs. You see, doesn't have a darwin maintainer. I think, I was the last person to fix it around last January. The problem is that it's hard to keep up with all the updates. Every "minor" Qt version bump brings serious breaking changes for on darwin (like they might not even support our version of SDK anymore...). To make things worse we port all those bumps to the stable branch, so it quickly breaks there too.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still important to me, many qt apps are broken on darwin due to this one.
Code change:
owner = "Ultimaker"; repo = "Cura"; rev = version; <del> sha256 = "1qnai8vmgy5lx3lapw96j41i8mw9p6r99i3qzs709l9yzrix6l86"; </del> <ins> sha256 = "1wf60qr0wqsci5skp55qr8h56s3x5s2icxbn58ia9s4a5hhvnsmf"; </ins> }; materials = fetchFromGitHub {

Related discussion:
text: Describe the bug Slicing fails on latest Cura (4.3). When trying to slice any model the slicing progress bar will get stuck at about ~20%. I tried various printer presets and the problem persists. From looking at the logs it seems like that CuraEngine is unable to get a value for 'machineheatedbuildvolume', which was To Reproduce Steps to reproduce the behavior: any printer preset any model Slice Cura log relevant parts to the problem seem to be aditional information it seems like , from the nix package, indeed is missing the new setting. For comparison the upstream definition. Metadata Maintainer information:
Code change:
, libdrm ? null , mesa   ? null <del> , alsaSupport        ? stdenv.isLinux, alsa-lib       ? null </del> <ins> , alsaSupport        ? stdenv.isLinux, alsa-lib      ? null </ins> , archiveSupport     ? true,           libarchive    ? null , bluraySupport      ? true,           libbluray     ? null , bs2bSupport        ? true,           libbs2b       ? null

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: mpv <!-- 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: 0.33.1 desired version: 0.34.0 <!-- 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:
rofi-unwrapped = callPackage ../applications/misc/rofi { }; rofi = callPackage ../applications/misc/rofi/wrapper.nix { }; <ins> rofi-wayland-unwrapped = callPackage ../applications/misc/rofi/wayland.nix { }; rofi-wayland = callPackage ../applications/misc/rofi/wrapper.nix { rofi-unwrapped = rofi-wayland-unwrapped; }; </ins> rofi-pass = callPackage ../tools/security/pass/rofi-pass.nix { };

Related discussion:
text: Project description A window switcher, application launcher and dmenu replacement (Wayland fork) Metadata homepage URL: license: mit platforms: linux
Code change:
<ins> { buildPythonPackage, fetchFromGitHub, lib, loguru, rpyc, }: buildPythonPackage rec { pname = "streamcontroller-plugin-tools"; version = "2.0.0"; src = fetchFromGitHub { owner = "StreamController"; repo = "streamcontroller-plugin-tools"; rev = version; hash = "sha256-dQZPRSzHhI3X+Pf7miwJlECGFgUfp68PtvwXAmpq5/s="; }; dependencies = [ loguru rpyc ]; pythonImportsCheck = [ "streamcontroller_plugin_tools" ]; meta = with lib; { description = "StreamController plugin tools"; homepage = "https://github.com/StreamController/streamcontroller-plugin-tools"; license = licenses.gpl3; maintainers = with maintainers; [ sifmelcara ]; platforms = platforms.linux; }; } </ins>

Related discussion:
text: Project description As discussed in is now EOL and the dev's have moved their effort to . As per the in order for it to work specific need to be set up. We can probably do something similar to what we do for the expression: Metadata homepage URL: source URL: license: GPL3 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
For people who subscribed to this issue: I opened to add streamcontroller
Code change:
<ins> { lib, vips, resvg, mpv, libraw, imagemagick, libdevil, stdenv, fetchFromGitLab, cmake, libarchive, qt6Packages, extra-cmake-modules, exiv2, }: stdenv.mkDerivation rec { pname = "previewqt"; version = "3.0"; src = fetchFromGitLab { owner = "lspies"; repo = "previewqt"; rev = "refs/tags/v${version}"; hash = "sha256-cDtqgezKGgSdhw8x1mM4cZ0H3SfUPEyWP6rRD+kRwXc="; }; # can't find qtquick3d strictDeps = false; nativeBuildInputs = [ cmake extra-cmake-modules qt6Packages.wrapQtAppsHook ]; buildInputs = [ exiv2 imagemagick qt6Packages.poppler qt6Packages.qtmultimedia qt6Packages.qtquick3d qt6Packages.qtsvg qt6Packages.qttools qt6Packages.qtwebengine libarchive libdevil libraw mpv resvg vips ]; meta = { description = "Qt-based file previewer"; homepage = "https://photoqt.org/previewqt"; changelog = "https://gitlab.com/lspies/previewqt/-/blob/v${version}/CHANGELOG"; license = lib.licenses.gpl2Plus; maintainers = with lib.maintainers; [ eclairevoyant ]; mainProgram = "previewqt"; platforms = lib.platforms.linux; }; } </ins>

Related discussion:
text: Project description PreviewQt is a simple application for previewing all kinds of files, based on Qt/QML, published as open-source and completely free. Metadata homepage URL: source URL: license: gpl2+ platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
, desktopName ? # browserName with first letter capitalized (lib.toUpper (lib.substring 0 1 browserName) + lib.substring 1 (-1) browserName) , nameSuffix ? "" <del> , icon ? browserName, libtrick ? true </del> <ins> , icon ? browserName </ins> }: let

Related discussion:
text: When "set as default browser" is clicked from within Firefox, it places a custom .desktop file in , and points to this from in the same directory. This file launches Firefox without the wrapper when it's opened using xdg-open. The result is that if xdg-open is used when no Firefox window exists, it will be opened without environment variables set correctly, and without plugins.
This is a great example why wrappers are error prone.
Is there a easy way to fix this? I don't see one
The easy way is to use a non-absolute path in the .desktop file, i.e. . This also ensures that after an upgrade, the new Firefox will be invoked.
This .desktop file is generated by Firefox when "set as default browser" is clicked - it's not one of nixpkgs's .desktop files. That'd involve a patch (which would have to be kept up to date with each Firefox release).
Right, shouldn't be hard to do.
Testing a patch now...
I can't see the patch anywhere -- did it work?
Chromium .desktop file includes and suffers from the same problem.
This is handled and detected with mimetypes.
Would be really nice to fix this one, any takers?
I think I have solved it for Firefox; as for Chromium — apparently it is non-trivial to test for me (StumpWM, not a DE)
There's still no obvious way to set the default browser that I can find - anyone know what the status is here?
A possibly reasonable option in the case of Firefox would be to disable the default browser check using the preferences file, and write a custom dialog for selecting the default browser in the wrapper itself, a very rough basis being: According to a google, similar should work for Chrome/Chromium, except passing instead of messing with config files. Opinions?
Is there no way to trick firefox into thinking its executable name is the wrapper ?
Yes: but this needs some testing, and it affects many browsers.
I fixed the wrapper to work with (), but we get another issue. When we update firefox, we end up with a different /nix path, which firefox considers as a different browser. If you restart firefox (for example when installing addons) then you get the not-your-default-browser" warning. Investaigating MOZAPPLAUNCHER as solution, but I start to think that may be the most general solution.
Code change:
sha256 = "05s9dclmk7x5d7wnnj4qr6r6c827m72a44gizcv09lxr28pr9inz"; fetchSubmodules = true; }; <del> # we need the packed archive </del> <ins> # The CMake external projects expect the packed archives </ins> rxcpp = fetchurl { url = "https://github.com/Reactive-Extensions/RxCpp/archive/v${rxcppVersion}.tar.gz"; sha256 = "0y2isr8dy2n1yjr9c5570kpc9lvdlch6jv0jvw000amwn5d3krsh";

Related discussion:
text: shogun fails to build since the eigen 3.4.0 bump: The package is a likely candidate for removal. Upstream is unresponsive and development has halted. Removed from debian: Removed from fedora: Blocking vcpkg update: Please run and paste the result. Maintainer information:
I think you were the last one to modify this package, so please speak up if you need it. Also pinging Last call - if no one responds within the next week, I'll open a PR to remove this package.
Yes, I was working on making it build on Darwin and adding it as a Python 3 module. Well, I did, but I didn't feel motivated to create a PR. As you comment, upstream has been inactive for almost a year, the latest release is several years old, and it becomes harder and harder to make it work, and the patches would start to accumulate. To make it work on Darwin we need two upstream patches that fix the build with newer compiler versions. In the current derivation, the Python interface is not built because the CMake flag is not the right one. When enabled, Swig 3 is used to generate the Python interface, but Swig 3 doesn't support Python 3.8+ (and with Swig 4 just fails). It can be fixed with a patch, that feels more like a hack, intercepting the Makefile build, so I am not happy with it: Another small patch is needed to fix the deprecated . Also, I wasn't happy that adding it as a Python module will recompile the entire library again, which takes too much time IMO. I haven't checked if it is possible to build with Eigen 3.4 because it takes forever to compile. It could probably work on the development version. Note that the development version doesn't support Eigen 3.4 because of this, but it may work: But there is no such limitation on the 6.1.4 release, which probably means it would require another patch to fix the code, if somebody figures out. So, I'd argue that the package is too old now, and the derivation has too many issues, and it's too much of a hassle to maintain it, so it's probably better to just remove it.
I decided to sit and take a look at the error, and I actually fixed it.