jiebi/CodeConvo huggingface dataset:
Code change:
in stdenv.mkDerivation rec { pname = "SunVox"; <del> version = "2.1c"; </del> <ins> version = "2.1.1c"; </ins> src = fetchurl { <del> url = "https://www.warmplace.ru/soft/sunvox/sunvox-${version}.zip"; sha256 = "sha256-yPVcbtlAVbO9uMsFlfZ51T408hA1VPJAI+R+Jdjcyjw="; </del> <ins> urls = [ "https://www.warmplace.ru/soft/sunvox/sunvox-${version}.zip" # Upstream removes downloads of older versions, please save bumped versions to archive.org "https://web.archive.org/web/20231204012052/https://www.warmplace.ru/soft/sunvox/sunvox-2.1.1c.zip" ]; sha256 = "sha256-LfBQ/f2X75bcqLp39c2tdaSlDm+E73GUvB68XFqiicw="; </ins> }; nativeBuildInputs = [ unzip ];

Related discussion:
text: Package name: sunvox Latest released version: v2.1.1c Notify maintainers
The current version in nixpkgs is not available so building fails. The hash of the new version is
Code change:
<ins> { buildGoModule , fetchFromGitHub , lib }: buildGoModule { pname = "dnss"; version = "0-unstable-2024-03-17"; src = fetchFromGitHub { owner = "albertito"; repo = "dnss"; rev = "da8986dd432870f5710e3e8652c92c95f34b830b"; hash = "sha256-YjBt+22fc9yHcORRmd//rejNVvf6eK+FAYAcT0fABuI="; }; vendorHash = "sha256-d9aGSBRblkvH5Ixw3jpbgC8lMW/qEYNJfLTVeUlos7A="; meta = with lib; { description = "A daemon for using DNS over HTTPS"; homepage = "https://blitiri.com.ar/git/r/dnss/"; license = licenses.asl20; mainProgram = "dnss"; maintainers = with maintainers; [ raspher ]; }; } </ins>

Related discussion:
text: Project description forwards dns over https queries to normal dns servers and vice versa. Metadata homepage URL: source URL: license: apache 2.0 platforms: unix, linux, darwin, ... ubuntu package url:
Upstream has system services. Is there a need to include these modules (services) within this package? I would prefer not to include them if there is no need, because is not actively developed and has not released a single stable version yet.
I personally don't need them, because I prefer creating systemd services via nix configuration anyways.
Code change:
, pkgconfig , file , protobufc <ins> , libiconv </ins> }: stdenv.mkDerivation rec { name = "postgis-${version}";

Related discussion:
text: Describe the bug has , preventing it from being used on other platforms, particularly Darwin in my case. To Reproduce nix-shell to get this error: error: Package ‘postgis-2.5.2’ in is not supported on ‘x8664-darwin’, refusing to evaluate. Expected behavior Produce a postgresql-and-plugins package with postgis available. Additional context Simply allowing doesn't work immediately because PostGIS' build system is quirky. There was some relevant-looking discussion on . Metadata system: host os: multi-user?: sandbox: version: channels(lukeworth): nixpkgs:
Code change:
bazel_3 = callPackage ../development/tools/build-managers/bazel/bazel_3 { inherit (darwin) cctools; inherit (darwin.apple_sdk.frameworks) CoreFoundation CoreServices Foundation; <del> buildJdk = jdk8; </del> <ins> buildJdk = jdk8_headless; </ins> buildJdkName = "jdk8"; runJdk = jdk11_headless; stdenv = if stdenv.cc.isClang then llvmPackages_6.stdenv else stdenv;

Related discussion:
text: Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in
Code change:
<ins> { stdenvNoCC, lib, fetchzip, }: stdenvNoCC.mkDerivation rec { pname = "catamaran"; version = "0-unstable-2024-03-02"; src = fetchzip { url = "https://www.1001fonts.com/download/catamaran.zip"; stripRoot = false; hash = "sha256-9s11lZSS4pYJZwl8Uk7qtdwfZ2bkoZkSIf1MkQlv7H4="; }; stripRoot = false; installPhase = '' runHook preInstall mkdir -p $out/share/fonts/truetype mv *.ttf $out/share/fonts/truetype/ runHook postInstall ''; meta = with lib; { homepage = "https://fonts.google.com/specimen/Catamaran"; description = "A stylish sans-serif Tamil and Latin typeface"; longDescription = '' Catamaran is a Unicode-compliant Latin and Tamil text type family designed for the digital age. The Tamil is monolinear and was designed alongside the sans serif Latin and Devanagari family Palanquin. It currently comprises of 9 text weights, making it a versatile family that strikes a balance between typographic conventions and that bit of sparkle. (A catamaran is a multihulled vessel consisting of two parallel hulls of equal size. The catamaran concept is a relative newcomer for Western boat designers, been used since time immemorial among the Dravidian people, in South India.) ''; license = licenses.ofl; platforms = platforms.all; maintainers = with maintainers; [wyred50]; }; } </ins>

Related discussion:
text: Project description Catamaran sans is a font for tamil language Metadata homepage URL: source URL: license: OFL platforms: ? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
<ins> { stdenv , lib , fetchFromGitHub , rofi-unwrapped , wayland-protocols , wayland }: rofi-unwrapped.overrideAttrs (oldAttrs: rec { pname = "rofi-wayland-unwrapped"; version = "1.7.2+wayland1"; src = fetchFromGitHub { owner = "lbonn"; repo = "rofi"; rev = version; fetchSubmodules = true; sha256 = "sha256-INFYHOVjBNj8ks4UjKnxLW8mL7h1c8ySFPS/rUxOWwo="; }; nativeBuildInputs = oldAttrs.nativeBuildInputs ++ [ wayland-protocols ]; buildInputs = oldAttrs.buildInputs ++ [ wayland ]; meta = with lib; { description = "Window switcher, run dialog and dmenu replacement for Wayland"; homepage = "https://github.com/lbonn/rofi"; license = licenses.mit; maintainers = with maintainers; [ bew ]; platforms = with platforms; linux; }; }) </ins>

Related discussion:
text: Project description A window switcher, application launcher and dmenu replacement (Wayland fork) Metadata homepage URL: license: mit platforms: linux
Code change:
, zlib , debugVersion ? false , enableManpages ? false <del> , enableSharedLibraries ? !stdenv.hostPlatform.isStatic </del> <ins> , enableSharedLibraries ? false </ins> , version , src

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:
, zlib , debugVersion ? false , enableManpages ? false <del> , enableSharedLibraries ? !stdenv.hostPlatform.isStatic </del> <ins> , enableSharedLibraries ? false </ins> , version , src

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:
, zlib , debugVersion ? false , enableManpages ? false <del> , enableSharedLibraries ? !stdenv.hostPlatform.isStatic </del> <ins> , enableSharedLibraries ? false </ins> , version , src

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:
, zlib , debugVersion ? false , enableManpages ? false <del> , enableSharedLibraries ? !stdenv.hostPlatform.isStatic </del> <ins> , enableSharedLibraries ? false </ins> , version , src

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:
<ins> { fetchFromGitHub , stdenvNoCC , lib , vcpkg-tool , writeShellScript }: stdenvNoCC.mkDerivation (finalAttrs: { pname = "vcpkg"; version = "2023.10.19"; src = fetchFromGitHub { owner = "microsoft"; repo = "vcpkg"; rev = finalAttrs.version; hash = "sha256-u+4vyOphnowoaZgfkCbzF7Q4tuz2GN1bHylaKw352Lc="; }; installPhase = let # vcpkg needs two directories to write to that is independent of installation directory. # Since vcpkg already creates $HOME/.vcpkg/ we use that to create a root where vcpkg can write into. vcpkgScript = writeShellScript "vcpkg" '' vcpkg_writable_path="$HOME/.vcpkg/root/" VCPKG_ROOT="@out@/share/vcpkg" ${vcpkg-tool}/bin/vcpkg  --x-downloads-root="$vcpkg_writable_path"/downloads  --x-buildtrees-root="$vcpkg_writable_path"/buildtrees  --x-packages-root="$vcpkg_writable_path"/packages  "$@" ''; in '' runHook preInstall mkdir -p $out/bin $out/share/vcpkg/scripts/buildsystems cp --preserve=mode -r ./{docs,ports,triplets,scripts,.vcpkg-root,versions,LICENSE.txt} $out/share/vcpkg/ substitute ${vcpkgScript} $out/bin/vcpkg --subst-var-by out $out chmod +x $out/bin/vcpkg ln -s $out/bin/vcpkg $out/share/vcpkg/vcpkg touch $out/share/vcpkg/vcpkg.disable-metrics runHook postInstall ''; meta = { description = "C++ Library Manager"; homepage = "https://vcpkg.io/"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ guekka gracicot ]; platforms = lib.platforms.all; }; }) </ins>

Related discussion:
text: Project description vcpkg is a package manager for C++ and many large and very small libraries are packaged there. Many of my projects use it for CMake configuration and for its toolchain file that automatically download and build libraries. I want to setup dev environment with nix and this is one of the packages I'm looking for that I've been building manually (since the brew packaged vcpkg is not well configured for manifest files support) Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, windows
I'll try something now.
Reading the , it looks like a case for a module, not merely a package.
I'm not sure what's the difference between a package and a module... but if it allows me to download a prebuilt binary of vcpkg that I can simply install, that's fine for me. Know that this package manager is made (partly) in C++ and need compiling. The build script is the you see there.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Maybe I am over-engineering here. Reading the AUR script, vcpkg uses systemd scripts/services. Therefore I think it requires more integration with the operating system. Modules are, roughly speaking, designed to "patch" and configure NixOS (the operating system).
Would be nice to have!
Work is ongoing here:
Code change:
, libpthreadstubs , libXdmcp , lndir <ins> , unixODBC </ins> , util-linux , libselinux

Related discussion:
text: Steps to reproduce the behavior: kicad (tested on ) The relevant part of the build log is: Complete build log is here: Setting the flag in the cmake build flags, solves the issue. Please run and paste the result.
thanks for filing an issue i'm not sure what changed to cause this issue, or why that change didn't notify me of the breakage... i'll try to get your fix or something similar in a PR today
Code change:
sha256 = "sha256-ORzcd8XGy2BfwuPK5UX+K5Z+FYkb+tdg/gHl3zHjvbk="; }; <del> # hardcoded because makefile target "install" depends on libxslt dependencies from network # that are just too hard to monkeypatch here # so this is the simple fix. installPhase = '' mkdir -p $out install -d $out/bin install -m755 fbcat $out/bin/ install -m755 fbgrab $out/bin/ install -d $out/share/man/man1 </del> <ins> postPatch = '' substituteInPlace fbgrab  --replace 'pnmtopng' '${netpbm}/bin/pnmtopng'  --replace 'fbcat' "$out/bin/fbcat" </ins> ''; <ins> installFlags = [ "PREFIX=${placeholder "out"}" ]; </ins> meta = with lib; { homepage = "http://jwilk.net/software/fbcat"; description = "Framebuffer screenshot tool";

Related discussion:
text: Steps to reproduce the behavior: working program Add any other context about the problem here. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Code change:
./0002-disable-gnc-fq-update.patch # this patch prevents the building of gnucash-valgrind ./0003-remove-valgrind.patch <ins> # this patch makes gnucash exec the Finance::Quote helpers directly ./0004-exec-fq-helpers.patch </ins> ]; # this needs to be an environment variable and not a cmake flag to suppress

Related discussion:
text: On NixOS 22.05, getting financial quotes in gnucash no longer works because the helper scripts are now binary wrappers, but gnucash calls so this fails. Commit suggests that should avoid this, but for some reason the scripts still get wrapped with binaries. NixOS 22.05..
I can reproduce this on my machine from nixpkgs/master, so it's not a 22.05 problem. Interestingly, when I backport GnuCash's derivation from nixpkgs/master back to a known-good commit (), things appear ok. I'll continue digging.
... I see you yourself as a maintainer. Any interest in taking a stab at this? Per I think we're being broken by a change somewhere related to .
... I see you yourself as a maintainer. Any interest in taking a stab at this? still getting my head together after a bad bout of covid, not sure I'll be able to work on anything serious any time soon
I worked around this on my nixos config by adding a patch () to execute the helpers directly without calling out to perl. It seems to work for me. Will this break anything? If desired, I can submit a PR with this patch. Also, the perl helpers seem to be getting wrapped explicitly () is this not the reason the perl helpers are getting wrapped with binary executables?
Code change:
substituteInPlace $out/lib/pkgconfig/mpv.pc  --replace "$out/include" "$dev/include" <del> '' + optionalString stdenv.isDarwin '' </del> <ins> '' + lib.optionalString stdenv.isDarwin '' </ins> mkdir -p $out/Applications cp -r build/mpv.app $out/Applications ''; # Set RUNPATH so that libcuda in /run/opengl-driver(-32)/lib can be found. # See the explanation in addOpenGLRunpath. <del> postFixup = optionalString stdenv.isLinux '' </del> <ins> postFixup = lib.optionalString stdenv.isLinux '' </ins> addOpenGLRunpath $out/bin/mpv ''; meta = with lib; { <del> description = "A media player that supports many video formats (MPlayer and mplayer2 fork)"; </del> homepage = "https://mpv.io"; <ins> description = "General-purpose media player, fork of MPlayer and mplayer2"; longDescription = '' mpv is a free and open-source general-purpose video player, based on the MPlayer and mplayer2 projects, with great improvements above both. ''; </ins> license = licenses.gpl2Plus; maintainers = with maintainers; [ AndersonTorres fpletz globin ma27 tadeokondrak ]; platforms = platforms.darwin ++ platforms.linux; <ins> }; </ins> <del> longDescription = '' mpv is a free and open-source general-purpose video player, based on the MPlayer and mplayer2 projects, with great improvements above both. ''; </del> <ins> passthru = { inherit # The wrapper consults luaEnv and lua.version luaEnv lua # In the wrapper, we want to reference vapoursynth which has the `python3` # passthru attribute (which has the `sitePrefix` attribute). This way we'll # be sure that in the wrapper we'll use the same python3.sitePrefix used to # build vapoursynth. vapoursynthSupport vapoursynth ; </ins> }; }

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:
, ninja , openssl , pkg-config <del> , python3 </del> , rustPlatform , sqlite , transmission

Related discussion:
text: Package name: fragments Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2.0.2 Current version on the stable/release channel: 2.0.2 <!-- 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.