jiebi/CodeConvo huggingface dataset:
Change:
# desktop item mkdir -p "$out/share" ln -s "${desktopItem}/share/applications" "$out/share/applications" <del> ''; postFixup = '' </del> # executable wrapper makeWrapper '${electron}/bin/electron' "$out/bin/${executableName}"  <del> --add-flags "$out/share/riot/electron"  "''${gappsWrapperArgs[@]}" </del> <ins> --add-flags "$out/share/riot/electron" </ins> ''; # Do not attempt generating a tarball for riot-web again.

Discussion:
Describe the bug The electron package tries to wrap in . Because of this the wrapper is completely void of any entries in . It needs to be rewritten in whatever fashion that the call happens in . This is why has needed to be wrapped recently , it's because isn't wrapped correctly itself. A change should be made to stable to revert this to riot-desktop, and to backport this fix instead. Expression: buildInputs should also have for it's setup-hook
I created a PR here:
Change:
<del> { lib, stdenv, fetchFromGitHub, cmake, pkg-config, makeWrapper , CoreFoundation, IOKit, libossp_uuid , nixosTests , bash, curl, jemalloc, json_c, libuv, zlib, libyaml, libelf, libbpf , libcap, libuuid, lm_sensors, protobuf , go, buildGoModule, ninja , withCups ? false, cups , withDBengine ? true, lz4 , withIpmi ? (!stdenv.isDarwin), freeipmi , withNetfilter ? (!stdenv.isDarwin), libmnl, libnetfilter_acct , withCloud ? false , withCloudUi ? false , withConnPubSub ? false, google-cloud-cpp, grpc , withConnPrometheus ? false, snappy , withSsl ? true, openssl , withSystemdJournal ? (!stdenv.isDarwin), systemd , withDebug ? false , withEbpf ? false , withNetworkViewer ? (!stdenv.isDarwin) </del> <ins> { lib, stdenv, fetchFromGitHub, bash, buildGoModule, cmake, cups, curl, darwin, freeipmi, go, google-cloud-cpp, grpc, jemalloc, json_c, libbpf, libcap, libelf, libmnl, libnetfilter_acct, libossp_uuid, libuuid, libuv, libyaml, lm_sensors, lz4, makeWrapper, ninja, nixosTests, openssl, overrideSDK, pkg-config, protobuf, snappy, systemd, withCloud ? false, withCloudUi ? false, withConnPrometheus ? false, withConnPubSub ? false, withCups ? false, withDBengine ? true, withDebug ? false, withEbpf ? false, withIpmi ? (stdenv.isLinux), withNetfilter ? (stdenv.isLinux), withNetworkViewer ? (stdenv.isLinux), withSsl ? true, withSystemdJournal ? (stdenv.isLinux), zlib, </ins> }: <del> stdenv.mkDerivation rec { version = "1.47.0"; </del> <ins> let stdenv' = if stdenv.isDarwin then overrideSDK stdenv "11.0" else stdenv; in stdenv'.mkDerivation (finalAttrs: { version = "1.47.1"; </ins> pname = "netdata"; src = fetchFromGitHub { owner = "netdata"; repo = "netdata"; <del> rev = "v${version}"; hash = if withCloudUi then "sha256-eMapy4HQaEblDfZt2uVSfBWRlkstX7TxZDBgSv5bW/I=" </del> <ins> rev = "v${finalAttrs.version}"; hash = if withCloudUi then "sha256-/iXmIjWpZ0s/LELZM7rYYQ9cjLNdfdisyOvDyLddSY4=" </ins> # we delete the v2 GUI after fetching <del> else "sha256-Gx7u3Owh/fVAnSw91xfdcmyx4m+bvQAvDaUxzXQ36/0="; </del> <ins> else "sha256-pAqxxsWYgqbmF6wFBfTCYYc3x/Ufyz2Xs4bwB1ToHjo="; </ins> fetchSubmodules = true; # Remove v2 dashboard distributed under NCUL1. Make sure an empty

Discussion:
Steps to reproduce the behavior: netdata 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. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Created a PR to fix the build, can you try it out ?
Change:
src = fetchurl { url = "https://downloads.vivaldi.com/stable/${product}-stable_${version}_amd64.deb"; <del> sha256 = "08x6abyz65vx4ycj8ys8sib9z1adb8ybmnrqjck69b30kbz78rj2"; </del> <ins> sha256 = "00rxp6rardxjg17g2b28y2rj8szqlainp4ga6c58z981zkxvdlls"; </ins> }; unpackPhase = ''

Discussion:
This probably isn't a strictly NixOS issue, but nevertheless should be mentioned. The hash for vivaldi-stable2.1.1337.51-1 has changed. The old one in nixpkgs is 08x6abyz65vx4ycj8ys8sib9z1adb8ybmnrqjck69b30kbz78rj2, while nix-env reports 00rxp6rardxjg17g2b28y2rj8szqlainp4ga6c58z981zkxvdlls. to unstable channels. -env -i vivaldi system: host os: multi-user?: sandbox: version: channels(void): channels(root): nixpkgs:
unfortunately, sometimes software projects update different package sources with different sha256sums on their website, which will then error during build, until it gets fixed again Can you add a Pull Request, updating the hash in
Change:
<ins> { lib , stdenv , fetchFromGitHub , nix-update-script , meson , ninja , gettext , python3 , desktop-file-utils , rustPlatform , pkg-config , glib , libhandy , gtk3 , openssl , alsaLib , libpulseaudio , wrapGAppsHook }: stdenv.mkDerivation rec { pname = "spot"; version = "0.1.14"; src = fetchFromGitHub { owner = "xou816"; repo = "spot"; rev = version; sha256 = "eHhbm1amTx3ngqsP32uDEdrhrBeurMftg5SToTQGX9o="; }; cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; hash = "sha256-jY7pWoY9IJi5hHVRS1gQKb+Vmfc+wxHvoAwupOtXXQs="; }; nativeBuildInputs = [ gettext meson ninja pkg-config python3 # for meson postinstall script gtk3 # for gtk-update-icon-cache glib # for glib-compile-schemas desktop-file-utils rustPlatform.rust.cargo rustPlatform.cargoSetupHook rustPlatform.rust.rustc wrapGAppsHook ]; buildInputs = [ glib gtk3 libhandy openssl alsaLib libpulseaudio ]; postPatch = '' chmod +x build-aux/cargo.sh patchShebangs build-aux/cargo.sh build-aux/meson/postinstall.py ''; passthru = { updateScript = nix-update-script { attrPath = pname; }; }; meta = with lib; { description = "Native Spotify client for the GNOME desktop"; homepage = "https://github.com/xou816/spot"; license = licenses.mit; maintainers = with maintainers; [ jtojnar ]; }; } </ins>

Discussion:
Project description Spot Gtk/Rust native Spotify client for the Gnome desktop. Only works with premium accounts! Based on librespot. Metadata homepage URL: source URL: license: mit platforms: unix/linux
Change:
src = fetchFromGitHub { owner = "geoffreybennett"; <del> repo = pname; </del> <ins> repo = "alsa-scarlett-gui"; </ins> rev = version; <del> sha256 = "sha256-+74JRQn2xwgPHZSrp5b+uny0+aLnsFvx/cOKIdj4J40="; </del> <ins> hash = "sha256-+74JRQn2xwgPHZSrp5b+uny0+aLnsFvx/cOKIdj4J40="; </ins> }; NIX_CFLAGS_COMPILE = [ "-Wno-error=deprecated-declarations" ]; makeFlags = [ "DESTDIR=${out}" "PREFIX=''" ]; sourceRoot = "${src.name}/src"; <ins> postPatch = '' substituteInPlace file.c  --replace-fail "/usr/sbin/alsactl" "${alsa-utils}/bin/alsactl" ''; </ins> nativeBuildInputs = [ pkg-config wrapGAppsHook4 makeWrapper ]; buildInputs = [ gtk4 alsa-lib openssl ]; postInstall = '' wrapProgram $out/bin/alsa-scarlett-gui --prefix PATH : ${lib.makeBinPath [ alsa-utils ]} substituteInPlace $out/share/applications/vu.b4.alsa-scarlett-gui.desktop  <del> --replace "Exec=/bin/alsa-scarlett-gui" "Exec=$out/bin/alsa-scarlett-gui" </del> <ins> --replace-fail "Exec=/bin/alsa-scarlett-gui" "Exec=$out/bin/alsa-scarlett-gui" </ins> ''; # causes redefinition of _FORTIFY_SOURCE

Discussion:
There is an option to save the configuration state that does not work because it tries to run which is not located at this path in NixOS the GUI to File -Save Configuration filename and click save It should save a file to the filesystem with the current configuration state.
Change:
environment.etc = let mkEtcLink = service: { <del> name = "frr/${service}.conf"; </del> <ins> name = "frr/${daemonName service}.conf"; </ins> value.source = configFile service; }; in

Discussion:
using frr-9.0.1 from nixos-23.11 results in failure of staticd.service: = true systemctl status staticd staticd used to work with option see Quick fix see below. maybe / want to insert themselves kindly into maintainers :-) system: host os: multi-user?: sandbox: version: channels(fd): channels(root): nixpkgs:
No, sorry. I'm a BIRD user, and I like it that way. Me writing that test and getting FRR over the finish line was some morbid curiosity. My only interest in FRR was bgp-evpn signaling fwiw.
Thanks even more for contributing! My quickfix for this issue is so far It seems, config file location with mgmtd is now instead of mgmtd is needed for staticd to get configured.
also mentions
yes, all daemons have as default config file, I'll try to adapt the nixos service accordingly to get rid of in all service definitions.
Please also test with: (should not have changed this).
Change:
makeFlags = [ "BINDIR=$(out)/bin" "SBINDIR=$(out)/sbin" <del> "LIBDIR=$(out)/lib" "INCDIR=$(out)/include" </del> "DATADIR=$(out)/share" "MANDIR=$(out)/share/man" "PERL=perl" <del> "bios" </del> ]; doCheck = false; # fails. some fail in a sandbox, others require qemu

Discussion:
pxelinux (from syslinux) is compiled without support for UEFI PXE boot: I had a quick look at getting it to compile uefi support but I didn't get very far. system: host os: multi-user?: sandbox: version: channels(root): channels(peter): nixpkgs:
Does the NixOS netboot image support UEFI boot? I did try netbooting NixOS (18.03) a few weeks ago with a pre-compiled iPXE UEFI loader. It started booting the kernel but failed to mount the initrd (kernel panic no root).
The image is using pxelinux.0 instead of lpxelinux.0 it seems and you need lpxelinux for HTTP support so maybe that's what is going on.
The http support seemed to worked just fine in my case. I did serve the iPXE UEFI loader via tftp, the kernel image and the initrd via http (initrd is too big to load trouble-free via tftp). The iPXE loader pulled bzImage and initrd via http and began booting the kernel. The kernel then failed to mount the ramdisk for some reason I do not understand. I solved the problem by setting 'Legacy mode' in the firmware (Supermicro) and booting everything in classical BIOS/PXE mode (no UEFI components involved). I can try to reproduce the problem and send you some screenshots if that helps. My vague guess is that the NixOS netboot image needs some modifications to be UEFI capable. I just wanted to raise awareness that there are potential problems with UEFI-PXE down the road.
IIRC, specifying on the kernel command line is required with EFI booting for some reason (edit: when booting with iPXE, that is).
would fix this.
Change:
concat('opt-', translate( attr[@name = 'name']/string/@value, <del> '*&lt; >[]:', '_______' </del> <ins> '*&lt; >[]:&quot;', '________' </ins> ))" /> <varlistentry> <term xlink:href="#{$id}">

Discussion:
doesn't quote attributes containing periods, so the output is identical for e.g. and . Steps to reproduce the behavior: It should return . Instead it returns . It also doesn't include quotes for components containing other non-attribute-valid chars such as spaces. This is more of an aesthetic issue as is unambiguous, though it bothers me. Not quoting components containing periods is a correctness issue. Right now it calls and checks if the output is identical to . It does have comments explaining that it allows options starting with digits, as well as placeholders like <namelib.strings.escapeNixIdentifierlib.strings.escapeNixIdentifier` and then modifying the regex to allow these additional values. My suggestion for such a regex is something like . This way most punctuation and all whitespace will cause quoting but it will still allow and . Alternatively it could be more conservative and only quote for spaces and periods, but it seems more reasonable to me to quote for arbitrary punctuation as well.
Note that my suggested regex takes advantage of the fact that doesn't seem to be unicode-aware, in that succeeds. This seems like a bug, so if Nix ever gains unicode support here, this might have to be modified to explicitly allow either common placeholder chars or just all non-ASCII chars.
This relates to and
Change:
hash = "sha256-INX8TOEumz4B5coSxhiV7opc3rYJuQXT2k1BJ3Aje1M="; }; <del> nativeBuildInputs = [ meson cmake ninja ]; </del> <ins> nativeBuildInputs = [ fixedMeson cmake ninja ]; </ins> meta = with lib;{ homepage = "https://github.com/marzer/tomlplusplus";

Discussion:
Steps to reproduce the behavior: Notable part: @ lines 43..48: Looks like a cmake incompatibility?? possibly connected to ? <!-- 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. system: host os: multi-user?: sandbox: version: channels(root): channels(anna): nixpkgs:
Can you try building it manually against the latest nixpkgs-unstable revision using ?
This is really weird. Looks like something went and replace the first occurrence of in the source files with in . This is how it's supposed to look:
This was already built against the latest at the time, around an hour ago. My system flake registry pins to it. I get the same result with .
this looks completely normal. what is going on?
I have done a bisection and it appears that the first bad commit was
After bisecting Meson, this bug was introduced by and is still present in master.
Yes, I am writing a fix right now
has been merged, but do you think you could make a PR to master to have prismlauncher use its own overriden meson and another PR to staging to undo that change, so that way prismlauncher is at least fixed in the master branch sooner than a few weeks from now and when staging hits master, it won't have that temp fix anymore? Thank you again!
Note that the package that's actually broken here is . But yes using a fixed version of Meson for this sounds like a good idea.
Change:
, expat, libdrm, xorg, wayland, wayland-protocols, openssl , llvmPackages, libffi, libomxil-bellagio, libva-minimal , libelf, libvdpau <del> , libglvnd , enableRadv ? true </del> <ins> , libglvnd, libunwind </ins> , galliumDrivers ? ["auto"] , driDrivers ? ["auto"] , vulkanDrivers ? ["auto"]

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:
<del> { lib , stdenv , darwin , fetchFromGitHub , copyDesktopItems , makeDesktopItem , libxkbcommon , openssl , pkg-config , rustPlatform , vulkan-loader , wayland , xorg }: rustPlatform.buildRustPackage rec { pname = "halloy"; version = "2024.3"; src = fetchFromGitHub { owner = "squidowl"; repo = "halloy"; rev = "refs/tags/${version}"; hash = "sha256-9yEkM65c8R71oQ0C54xZqwRh609+HSaq4Hb8izNM52A="; }; cargoLock = { lockFile = ./Cargo.lock; outputHashes = { "iced-0.12.0" = "sha256-LtmAJDUMp42S4E+CjOM6Q7doAKOZkmJCN/49gsq3v/A="; "winit-0.29.10" = "sha256-YoXJEvEhMvk3pK5EbXceVFeJEJLL6KTjiw0kBJxgHIE="; }; }; nativeBuildInputs = [ copyDesktopItems pkg-config ]; buildInputs = [ libxkbcommon openssl vulkan-loader xorg.libX11 xorg.libXcursor xorg.libXi xorg.libXrandr ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk.frameworks.AppKit darwin.apple_sdk.frameworks.CoreFoundation darwin.apple_sdk.frameworks.CoreGraphics darwin.apple_sdk.frameworks.Cocoa darwin.apple_sdk.frameworks.Foundation darwin.apple_sdk.frameworks.Metal darwin.apple_sdk.frameworks.QuartzCore darwin.apple_sdk.frameworks.Security ] ++ lib.optionals stdenv.isLinux [ wayland ]; desktopItems = [ (makeDesktopItem { name = "org.squidowl.halloy"; desktopName = "Halloy"; comment = "IRC client written in Rust"; icon = "org.squidowl.halloy"; exec = pname; terminal = false; mimeTypes = [ "x-scheme-handler/irc" "x-scheme-handler/ircs" ]; categories = [ "Network" "IRCClient" ]; keywords = [ "IM" "Chat" ]; startupWMClass = "org.squidowl.halloy"; }) ]; postFixup = lib.optional stdenv.isLinux ( let rpathWayland = lib.makeLibraryPath [ wayland vulkan-loader libxkbcommon ]; in '' rpath=$(patchelf --print-rpath $out/bin/halloy) patchelf --set-rpath "$rpath:${rpathWayland}" $out/bin/halloy ''); postInstall = '' install -Dm644 assets/linux/org.squidowl.halloy.png $out/share/icons/hicolor/128x128/apps/org.squidowl.halloy.png ''; meta = with lib; { description = "IRC application"; homepage = "https://github.com/squidowl/halloy"; changelog = "https://github.com/squidowl/halloy/blob/${version}/CHANGELOG.md"; license = licenses.gpl3Only; maintainers = with maintainers; [ fab ]; mainProgram = "halloy"; }; } </del>

Discussion:
Package name: halloy Latest released version: 2024.5 <!-- Search your package here: --- Current version on the unstable channel: 2024.3 Current version on the stable/release channel: 2023.5 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
''; desktopItem = makeDesktopItem { <del> name = "zotero-${version}"; </del> <ins> name = "zotero"; </ins> exec = "zotero -url %U"; icon = "zotero"; comment = meta.description;

Discussion:
On each update, the desktop file in $out/share/applications changes name. I have the launcher pinned in latte-dock, but after each update, I have to unpin it and repin it again, or edit the configuration file for latte-dock. Is there a specific reason to keep the version in the name of the file? I think the only advantage would be if someone keeps various versions of zotero installed side-by-side, but for me, it is more of a drawback. Desktop file keeps the same name over updates. Please run and paste the result.
Change:
<del> { lib, stdenv, fetchurl, appimageTools, makeWrapper, electron_25 }: stdenv.mkDerivation rec { pname = "blockbench-electron"; version = "4.8.1"; src = fetchurl { url = "https://github.com/JannisX11/blockbench/releases/download/v${version}/Blockbench_${version}.AppImage"; sha256 = "sha256-CE2wDOt1WBcYmPs4sEyZ3LYvKLequFZH0B3huMYHlwA="; name = "${pname}-${version}.AppImage"; }; appimageContents = appimageTools.extractType2 { name = "${pname}-${version}"; inherit src; }; dontUnpack = true; dontConfigure = true; dontBuild = true; nativeBuildInputs = [ makeWrapper ]; installPhase = '' runHook preInstall mkdir -p $out/bin $out/share/${pname} $out/share/applications cp -a ${appimageContents}/{locales,resources} $out/share/${pname} cp -a ${appimageContents}/blockbench.desktop $out/share/applications/${pname}.desktop cp -a ${appimageContents}/usr/share/icons $out/share substituteInPlace $out/share/applications/${pname}.desktop  --replace 'Exec=AppRun' 'Exec=${pname}' runHook postInstall ''; postFixup = '' makeWrapper ${electron_25}/bin/electron $out/bin/${pname}  --add-flags $out/share/${pname}/resources/app.asar  --prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath [ stdenv.cc.cc ]}" ''; meta = with lib; { description = "A boxy 3D model editor powered by Electron"; homepage = "https://blockbench.net/"; license = licenses.gpl3Only; maintainers = with maintainers; [ ckie ]; platforms = [ "x86_64-linux" ]; }; } </del>

Discussion:
Package name: blockbench-electron Latest released version: 4.9.3 <!-- Search your package here: --- Current version on the unstable channel: 4.8.1 Current version on the stable/release channel: 4.8.1 <!-- 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. --Misc: Noticed this when trying to enter a nix shell with this package, resulting in an electron-25.9.0 EOL error. Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Okay, so I took a look at updating blockbench to a version with uses and but it looks like after 2 seconds, electron crashes. It's probably got to do something with , but I don't have much experience with it. Tried to debug it with , but it didn't really show me anything helpful. I even tried packaging from source, but it has the same issue.
Okay, so I did some more testing, and it looks like itself is the issue, and above work fine. I'll make a PR with the update.
Change:
in '' # xorg.xrandr needed for LWJGL [2.9.2, 3) https://github.com/LWJGL/lwjgl/issues/128 wrapQtApp $out/bin/polymc  <del> --set GAME_LIBRARY_PATH /run/opengl-driver/lib:${libpath}  </del> <ins> --set LD_LIBRARY_PATH /run/opengl-driver/lib:${libpath}  </ins> --prefix POLYMC_JAVA_PATHS : ${lib.makeSearchPath "bin/java" jdks}  --prefix PATH : ${lib.makeBinPath [ xorg.xrandr ]} '';

Discussion:
On my system PolyMC 1.4.0 and 1.4.1 fails to launch any instance I've tested up to Minecraft 1.12.2 due to apparently missing : Before upgrading from 1.3.2 -1.4.0 this did not occur. Steps to reproduce the behavior: PolyMC 1.4.1 from nixos-unstable to start any Minecraft version before 1.13 (tested with a1.0.4, 1.7.10, 1.8.9 and 1.12.2) The game should launch. This was first discussed in PolyMC/PolyMC, but closed by the author. As seen in over there, I also encounter a problem with versions 1.13 upwards. In those versions the game launches but fails to open an OpenAL device, resulting in sound not working. If others can reproduce this behavior I would like to include it with this bug report. <!-- 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.
Fixed with , thank you!