Question:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks

luaossl,,,,,5.1, luaposix,,,,34.1.1-1,,vyp lblasc luarepl,,,,,, <ins> luarocks,,,,,,mrcjkb teto </ins> luarocks-build-rust-mlua,,,,,,mrcjkb luarocks-build-treesitter-parser,,,,,,mrcjkb luasec,,,,,,flosse


Question:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks

{ lib , lua , wrapLua <del> , luarocks </del> <ins> , luarocks_bootstrap </ins> , writeTextFile # Whether the derivation provides a lua module or not.


Question:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks

nativeBuildInputs = [ lua  # for lua.h wrapLua <del> luarocks </del> <ins> luarocks_bootstrap </ins> ]; inherit doCheck extraConfig rockspecFilename knownRockspec externalDeps nativeCheckInputs;


Question:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks

buildInputs = let # example externalDeps': [ { name = "CRYPTO"; dep = pkgs.openssl; } ] externalDeps' = lib.filter (dep: !lib.isDerivation dep) self.externalDeps; <del> in [ lua.pkgs.luarocks ] </del> <ins> in [ luarocks_bootstrap ] </ins> ++ buildInputs ++ lib.optionals self.doCheck ([ luarocksCheckHook ] ++ self.nativeCheckInputs) ++ (map (d: d.dep) externalDeps')


Question:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks

}; }) {}; <ins> luarocks = callPackage({ buildLuarocksPackage, fetchFromGitHub, fetchurl }: buildLuarocksPackage { pname = "luarocks"; version = "3.11.0-1"; knownRockspec = (fetchurl { url    = "mirror://luarocks/luarocks-3.11.0-1.rockspec"; sha256 = "0pi55445dskpw6nhrq52589h4v39fsf23c0kp8d4zg2qaf6y2n38"; }).outPath; src = fetchFromGitHub { owner = "luarocks"; repo = "luarocks"; rev = "v3.11.0"; hash = "sha256-mSwwBuLWoMT38iYaV/BTdDmmBz4heTRJzxBHC0Vrvc4="; }; meta = { homepage = "http://www.luarocks.org"; description = "A package manager for Lua modules."; maintainers = with lib.maintainers; [ mrcjkb teto ]; license.fullName = "MIT"; }; }) {}; </ins> luarocks-build-rust-mlua = callPackage({ buildLuarocksPackage, fetchFromGitHub, fetchurl }: buildLuarocksPackage { pname = "luarocks-build-rust-mlua";


Question:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks

, vimPlugins , vimUtils , yajl <ins> , zip , unzip </ins> , zlib , zziplib }:


Question:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks

]; }); <ins> # As a nix user, use this derivation instead of "luarocks_bootstrap" luarocks = prev.luarocks.overrideAttrs (oa: { nativeBuildInputs = oa.nativeBuildInputs ++ [ installShellFiles lua unzip ]; # cmake is just to compile packages with "cmake" buildType, not luarocks itself dontUseCmakeConfigure = true; propagatedBuildInputs = [ zip unzip cmake ]; postInstall = lib.optionalString (stdenv.buildPlatform.canExecute stdenv.hostPlatform) '' installShellCompletion --cmd luarocks  --bash <($out/bin/luarocks completion bash)  --fish <($out/bin/luarocks completion fish)  --zsh <($out/bin/luarocks completion zsh) installShellCompletion --cmd luarocks-admin  --bash <($out/bin/luarocks-admin completion bash)  --fish <($out/bin/luarocks-admin completion fish)  --zsh <($out/bin/luarocks-admin completion zsh) ''; meta = oa.meta // { mainProgram = "luarocks"; }; }); </ins> luasec = prev.luasec.overrideAttrs (oa: { externalDeps = [ { name = "OPENSSL"; dep = openssl; }


Question:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks

<ins> /* This is a minimal/manual luarocks derivation used by `buildLuarocksPackage` to install lua packages. As a nix user, you should use the generated lua.pkgs.luarocks that contains a luarocks manifest which makes it recognizable to luarocks. Generating the manifest for luarocks_bootstrap seemed too hackish, which is why we end up with two "luarocks" derivations. */ </ins> { lib , stdenv , fetchFromGitHub


Question:
luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks

inherit (pkgs.buildPackages) makeSetupHook makeWrapper; }; <del> luarocks = toLuaModule (callPackage ../development/tools/misc/luarocks/default.nix { }); </del> <ins> luarocks_bootstrap = toLuaModule (callPackage ../development/tools/misc/luarocks/default.nix { }); </ins> # a fork of luarocks used to generate nix lua derivations from rockspecs luarocks-nix = toLuaModule (callPackage ../development/tools/misc/luarocks/luarocks-nix.nix { });


Question: Steps to reproduce the behavior: archivy Add any other context about the problem here. nixos 24.05, nixos-unstable at Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

wtforms = super.wtforms.overridePythonAttrs (oldAttrs: rec { version = "2.3.1"; <del> src = oldAttrs.src.override { </del> <ins> src = fetchPypi { pname = "WTForms"; </ins> inherit version; sha256 = "sha256-hhoTs65SHWcA2sOydxlwvTVKY7pwQ+zDqCtSiFlqGXI="; };


Question: Project description Instrument your LLM app with decorators or low-level SDK and get detailed tracing/observability. Works with any LLM or framework <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit platforms: linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<ins> { lib, buildPythonPackage, fetchFromGitHub, backoff, httpx, idna, langchain, llama-index, openai, packaging, poetry-core, pydantic, pythonRelaxDepsHook, wrapt, }: buildPythonPackage rec { pname = "langfuse"; version = "2.33.1"; pyproject = true; src = fetchFromGitHub { owner = "langfuse"; repo = "langfuse-python"; rev = "refs/tags/v${version}"; hash = "sha256-ZPCL3Xle4qEw2pNIcja252meep26W/RbVEk2suzywYI="; }; build-system = [ poetry-core ]; nativeBuildInputs = [ pythonRelaxDepsHook ]; pythonRelaxDeps = [ "packaging" ]; dependencies = [ backoff httpx idna packaging pydantic wrapt ]; optional-dependencies = { langchain = [ langchain ]; llama-index = [ llama-index ]; openai = [ openai ]; }; pythonImportsCheck = [ "langfuse" ]; # tests require network access and openai api key doCheck = false; meta = { description = "Instrument your LLM app with decorators or low-level SDK and get detailed tracing/observability"; homepage = "https://github.com/langfuse/langfuse-python"; changelog = "https://github.com/langfuse/langfuse-python/releases/tag/${src.rev}"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ natsukium ]; }; } </ins>


Question: Project description Instrument your LLM app with decorators or low-level SDK and get detailed tracing/observability. Works with any LLM or framework <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit platforms: linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

langdetect = callPackage ../development/python-modules/langdetect { }; <ins> langfuse = callPackage ../development/python-modules/langfuse { }; </ins> langid = callPackage ../development/python-modules/langid { }; langsmith = callPackage ../development/python-modules/langsmith { };


Question:
Steps to reproduce the behavior: radicale at quick glance I think they rereleased tarballs with more changes, files inside are from today Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Yeah, looks like upstream changed the release afterwards. I didn't even know you can do that on GitHub.
You can just delete the tag, create a new one with the same name and do a force push. Some projects do this, some don't.
I suggest any that do be removed from Nixpkgs. It's unacceptable.
Can someone revert for now?

python3.pkgs.buildPythonApplication rec { pname = "radicale"; <del> version = "3.2.1"; </del> <ins> version = "3.2.0"; </ins> pyproject = true; src = fetchFromGitHub { owner = "Kozea"; repo = "Radicale"; rev = "v${version}"; <del> hash = "sha256-OUwznn71xl8oWkw90fT1NYYZOuD83k+B5zLhygp1VQQ="; </del> <ins> hash = "sha256-RxC8VOfdTXJZiAroDHTKjJqGWu65Z5uyb4WK1LOqubQ="; </ins> }; postPatch = ''


Question: Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

{ lib , stdenv <del> , fetchgit </del> <ins> , fetchFromRepoOrCz , gnu-efi </ins> , fetchurl <ins> , fetchpatch </ins> , libuuid , makeWrapper , mtools , nasm <ins> , nixosTests </ins> , perl , python3 }:


Question: Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

# This is syslinux-6.04-pre3^1; syslinux-6.04-pre3 fails to run. # Same issue here https://www.syslinux.org/archives/2019-February/026330.html <del> src = fetchgit { url = "https://repo.or.cz/syslinux"; </del> <ins> src = fetchFromRepoOrCz { repo = "syslinux"; </ins> rev = "b40487005223a78c3bb4c300ef6c436b3f6ec1f7"; <del> sha256 = "sha256-GqvRTr9mA2yRD0G0CF11x1X0jCgqV4Mh+tvE0/0yjqk="; fetchSubmodules = true; </del> <ins> hash = "sha256-XNC+X7UYxdMQQAg4MLACQLxRNnI5/ZCOiCJrEkKgPeM="; </ins> }; patches = let


Question: Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

"0018-prevent-pow-optimization.patch" "26f0e7b2" "sha256-dVzXBi/oSV9vYgU85mRFHBKuZdup+1x1BipJX74ED7E=") <ins> # Fixes build with "modern" gnu-efi ./import-efisetjmp.patch </ins> ]; postPatch = '' <del> substituteInPlace Makefile --replace /bin/pwd $(type -P pwd) substituteInPlace utils/ppmtolss16 --replace /usr/bin/perl $(type -P perl) </del> <ins> substituteInPlace Makefile --replace-fail /bin/pwd $(type -P pwd) substituteInPlace utils/ppmtolss16 --replace-fail /usr/bin/perl $(type -P perl) </ins> # fix tests substituteInPlace tests/unittest/include/unittest/unittest.h  <del> --replace /usr/include/ "" # Hack to get `gcc -m32' to work without having 32-bit Glibc headers. mkdir gnu-efi/inc/ia32/gnu touch gnu-efi/inc/ia32/gnu/stubs-32.h </del> <ins> --replace-fail /usr/include/ "" </ins> ''; nativeBuildInputs = [


Question: Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

buildInputs = [ libuuid <ins> gnu-efi </ins> ]; # Fails very rarely with 'No rule to make target: ...'


Question: Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

"MANDIR=$(out)/share/man" "PERL=perl" "HEXDATE=0x00000000" <ins> # Works around confusing (unrelated) error messages when upx is not made available "UPX=false" # Configurations needed to make use of external gnu-efi "LIBEFI=${gnu-efi}/lib/libefi.a" "LIBDIR=${gnu-efi}/lib/" "EFIINC=${gnu-efi}/include/efi" # Legacy bios boot target is always built "bios" </ins> ] <del> ++ lib.optionals stdenv.hostPlatform.isi686 [ "bios" "efi32" ]; </del> <ins> # Build "ia32" EFI for i686 ++ lib.optional stdenv.hostPlatform.isi686 "efi32" # Build "x86_64" EFI for x86_64 ++ lib.optional stdenv.hostPlatform.isx86_64 "efi64" ; </ins> # Some tests require qemu, some others fail in a sandboxed environment doCheck = false;


Question: Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

rm -rf $out/share/syslinux/com32 ''; <ins> passthru.tests.biosCdrom = nixosTests.boot.biosCdrom; </ins> meta = with lib; { <del> homepage = "http://www.syslinux.org/"; </del> <ins> homepage = "https://www.syslinux.org/"; </ins> description = "A lightweight bootloader"; license = licenses.gpl2Plus; maintainers = [ maintainers.samueldr ];


Question: Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<ins> From 68defee52f4eba82eefaeea17f21c7498448dd6b Mon Sep 17 00:00:00 2001 From: Samuel Dionne-Riel <samuel@dionne-riel.com> Date: Mon, 3 Jun 2024 16:16:25 -0400 Subject: [PATCH] efi/efi.h: Add efisetjmp.h See https://github.com/ncroxon/gnu-efi/commit/486ba3c3bdd147b7d98159b9e650be60bce0f027 --- efi/efi.h | 1 + 1 file changed, 1 insertion(+) diff --git a/efi/efi.h b/efi/efi.h index c266532f3..e4497574b 100644 --- a/efi/efi.h +++ b/efi/efi.h @@ -23,6 +23,7 @@ #include <efi.h> #include <efilib.h> #include <efistdarg.h> +#include <efisetjmp.h> /* Delay for 100 ms */ #define EFI_NOMAP_PRINT_DELAY	100 </ins>


Question: Project description <!-- Describe the project a little: -- alternative for GNOME (I guess) Metadata homepage URL: source URL: license: gpl3Only platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<ins> { lib, stdenv, fetchFromGitHub, rustPlatform, cargo, rustc, meson, ninja, pkg-config, appstream, blueprint-compiler, desktop-file-utils, gettext, wrapGAppsHook4, libadwaita, }: stdenv.mkDerivation (finalAttrs: { pname = "keypunch"; version = "1.0"; src = fetchFromGitHub { owner = "bragefuglseth"; repo = "keypunch"; rev = "refs/tags/v${finalAttrs.version}"; hash = "sha256-S4RckHwrVVQrxy9QngTisNM4+cMM+1dXucwEDnM98Rg="; }; cargoDeps = rustPlatform.fetchCargoTarball { name = "${finalAttrs.pname}-${finalAttrs.version}"; inherit (finalAttrs) src; hash = "sha256-YzENAGy7zEu1dyuhme+x+gJQlE74Vw0JZvRso0vNQXs="; }; strictDeps = true; nativeBuildInputs = [ rustPlatform.cargoSetupHook cargo rustc meson ninja pkg-config appstream blueprint-compiler desktop-file-utils gettext wrapGAppsHook4 ]; buildInputs = [ libadwaita ]; meta = { description = "Practice your typing skills"; homepage = "https://github.com/bragefuglseth/keypunch"; license = lib.licenses.gpl3Plus; mainProgram = "keypunch"; maintainers = with lib.maintainers; [ tomasajt ]; }; }) </ins>


Question:
Sometime between 23.11 and now, the binary broke due to a linking issue. Steps to reproduce the behavior:
fixes it of course, but I don't see an obvious less brutal approach.
adding to the works for me.
Good point, somehow thought this was already the case. PR up.

llvmPackages, python3, stdenv, <ins> testers, </ins> zlib, # Boolean flags withHTML ? true,


Question:
Sometime between 23.11 and now, the binary broke due to a linking issue. Steps to reproduce the behavior:
fixes it of course, but I don't see an obvious less brutal approach.
adding to the works for me.
Good point, somehow thought this was already the case. PR up.

nativeBuildInputs = [ cmake <del> (lib.getDev llvm) </del> ] ++ lib.optionals (withManual || withHTML) [ sphinx


Question:
Sometime between 23.11 and now, the binary broke due to a linking issue. Steps to reproduce the behavior:
fixes it of course, but I don't see an obvious less brutal approach.
adding to the works for me.
Good point, somehow thought this was already the case. PR up.

buildInputs = [ libffi libxml2 <ins> llvm </ins> zlib ] ++ lib.optionals (!stdenv.isDarwin) [ libclang ]; cmakeFlags = [ <del> (lib.cmakeOptionType "path" "CLANG_RESOURCE_DIR" "${lib.getDev libclang}") </del> <ins> (lib.cmakeOptionType "path" "CLANG_RESOURCE_DIR" "${lib.getLib libclang}/lib/clang/${lib.versions.major libclang.version}") </ins> (lib.cmakeBool "SPHINX_HTML" withHTML) (lib.cmakeBool "SPHINX_MAN" withManual) ] ++ lib.optionals stdenv.isDarwin [ (lib.cmakeOptionType "path" "Clang_DIR" "${lib.getDev libclang}/lib/cmake/clang") ]; <del> # 97% tests passed, 97 tests failed out of 2881 # mostly because it checks command line and nix append -isystem and all doCheck = false; </del> <ins> doCheck = true; </ins> strictDeps = true; <del> # -E exclude 4 tests based on names # see https://github.com/CastXML/CastXML/issues/90 checkPhase = '' runHook preCheck ctest -E 'cmd.cc-(gnu|msvc)-((c-src-c)|(src-cxx))-cmd' runHook postCheck ''; </del> <ins> passthru.tests = testers.testVersion { package = finalAttrs.finalPackage; }; </ins> meta = { homepage = "https://github.com/CastXML/CastXML";


Question:
(///) packaged in does not detect Muse Sounds Manager. The Muse Sounds profile is greyed out and cannot be used; leaving only MuseScore Basic available to use. Steps to reproduce the behavior: from (at the time of updating, version ) the unofficially packaged ) flake. MuseScore either from the desktop entry or via in a terminal, visit in the top bar, to check for available playback sounds to use. The Muse Sounds profile should be available to use and not greyed out. ! I have acknowledged the fact that although the mentioned Muse Sounds Manager package is unofficially packaged, the package works with the AppImage Version of MuseScore (packaged officially ), so I don't think this is the problem with the Muse Sounds Manager flake. Below is the screenshot of what the Playback Setup window should look like, taken from the AppImage version while opening the same score as the previous screenshot. ! I have tried reinstalling Muse Sounds Manager itself and reinstalling each Muse Sounds, but the issue persists. My entire system configuration files are . <!-- 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]:
Sorry, miss-clicked submitting the issue without adding any information. It'll be updated soon and reopened later.
Hey I'm sorry but I can't reproduce your issue. I Ran and downloaded an example font, and with both 4.3.0 and 4.3.1 I get: ! Before I downloaded the sound fonts I also had that button grayed out. Maybe you simply need to check again?
Thank you for responding. The issue persists after I've tried and and everything else (reinstalling MuseScore, Muse Sounds Manager, reinstalling all combinations of Muse Sounds) again to confirm that this is not an isolated incident. Additionally, I've compared the logs of both the AppImage version and the version. Most of both outputs are identical (apart from some timestamp-dependent data), but these lines only show up on the version: If necessary, please let me know how I can provide any more information.
Nice! Perhaps it is related to specific sound files you downloaded with that I didn't? Perhaps can you share all those? I have only this one named .
I've tried and downloaded all Muse Sounds from the beginning again for another time just for good measure. Here's an exact order of what I've tried (only one at a time, uninstalling all other Muse Sounds) and the issue still persists: Keys Brass Guitars Vol. 1 Choir Harp Percussion Strings Woodwinds So, all of the Muse Sounds available. The terminal logs print out the same error message on the version. I've also tried each of these with the AppImage version and I can confirm all of these are recognised with no issues. Is this in some ways related to how ? (This is an uneducated guess from me noticing logs mentioning the dynamic library )
Hey and sorry it took me a while to get back to this. It'd be nice to get your approval upon the 4.3.2 version bump (haven't even built it yet): So I tried to download all of the sounds mentioned above, and still I can see the muse sounds profile... I don't know what else I can suggest to debug this :/ Wait where do you see these lines? I don't see them in either muse-sounds-manager's logs nor in Musescore's ... Log of muse-sounds-manager-nix : And log of Musescore:
It's all good :) I'm just happy someone is even looking into this, to begin with. As to the 4.3.2 version bump, what do you need my approval of specifically? I'm sorry, I'm still very unfamiliar with the Nix ecosystem as a whole. Although, I have built the 4.3.2 on my machine and tried , everything seems to work (I've tried playing some tracks, editing them, etc), including the Muse Sounds. ! Additionally, I've done some more debugging: It seems like: running in the terminal (tested with + ) doing and then in the terminal (tested with & ) launching from the Desktop Entry all had the issue of Muse Sounds not being available to use. However, doing: (in ) / (in ) , into the output directory, then do all have Muse Sounds available to use. So this seems to be more of an issue with my shell environment somehow, and I honestly have no clue why this is the case, or where to start looking. That's a bummer. I mean, I guess I could always just use the AppImage version; It's not a big deal. Thank you for looking into it at least. Honestly, it could just be something arbitrary only in my machine in particular. Sorry, I should've clarified: The logs I sent earlier are from MuseScore (I just ran in the terminal). I didn't share Muse Sounds Manager's logs since nothing seems out of place there. Here's the full logs of me only running in the terminal and then closing the MuseScore window shortly afterwards: As you can see, line 9~12 showed the error I mentioned earlier. Again, thank you for taking your time looking into this.
Indeed this line seems suspicious.. And when you run version 4.3.2 you don't see it? I didn't find that line in my logs as well...
Yes, all other mentioned methods with Muse Sounds available don't have those errors in the logs.
It's weird because returns nothing... There is: Which may be related.
Edit: I was mistaken, setting the still doesn't detect Muse Sounds.
Yes it surprised you wrote initially it worked for you. We are on NixOS after all :). I'm not sure if you are subscribed to that issue or not, but I asked them about the source of .
BTW today I experienced crashing for me, and I checked the backtrace () and this is what I found: Interestingly: So indeed this issue is related to external shared objects that are not compatible with NixOS. I'm still a bit confused as to why in your case it doesn't necessarily crash, and instead it silently fails and you don't see the muse sounds... It'd be interesting to try to that file before you run ... In anycase, this should also be discussed with .
Hello, I've done some additional testing. It's not much, but I still want to tell you what I've found. It turns out these only work with that one MuseScore instance. From that instance, if I do or , it will always fail to load the dynamic library. I haven't yet figured out how to launch the new instance and have the dynamic library properly loaded. So this must be something weird about my variables, some directory mismatch, or something else. I've already sent my here, but in case you haven't taken a look, I have in it (which in turn makes return ), in case there are some hard-coded paths that don't respect this nix setting and is messing up with the dynamic library lookup. Just bringing it up since there have been some Nix packages not respecting that setting and causing issues with me in the past.
Hey did you end up finding a solution to this? I'm experiencing the exact same thing, and this thread is the only place mentioning these issues
Unfortunately, no, I haven't. Whenever I need to use MuseScore with MuseSounds (which is, all of the time), I launch MuseScore by doing in the terminal, which is one of the workarounds I've stated which have MuseSounds working.
Alright, thanks! Yeah I've seen your comment above, and to my surprise did indeed work. Maybe I'll just overwrite the mscore.desktop file with this command for now (Btw, thanks for the debugging effort you've put tinto this)
is not an issue due to the way library lookup works on Linux. Since is an optional dependency, it is loaded with (in via ), and says in particular that dependencies of such libraries are looked up in directories of the executable that calls . is a C++ application, so it also depends on and its contains a /nix/store directory with , and when it loads , the latter uses the same from the nix store. You can run to confirm that it has and that its contains the directory where it is located ()
The reason , etc. do not load is that the latter contains a shady function that prevents this library from loading when the calling process name () does not end with or . When you run MuseScore in the console from PATH, the process name is simply (without ), and the library declines to load. Similarly when you open a new score from MuseScore, it launches another instance of the program with the name which also does not end with .
the f. Amazing job figuring that out! (And also thanks for the MuseSounds nixpkgs PR )
Indeed this is a very impressive investigation and conclusion . I'm a bit confused though - whether we use a wrapper or not shouldn't make a difference right? Because the wrapper script (whether it is or ) always set to right - hence the shady function will return , at least as a of right? I wonder whether we should perform a to an absolute path in to improve 's experience described here.
I have already made a fix and will make a PR out of it very soon. MuseScore's argv0 will always end with regardless of the way it is launched, so can stay the same. (In my experience during system upgrades .desktop files are more convenient without absolute paths.)
You are right about the initial launch of MuseScore, but when you use File -New, it launches another copy of MuseScore, and it does this (as is common on Linux) by executing the target of , which is and this becomes of the new instance of MuseScore.
That's my experience as well. Ah wow, now I understand! Thanks. It means the patch will be much more involved... Good luck with that! I wonder why upstream decided to add that "check argv[0]` in the first place. The 4.4.2 release just came out, and the build locally seem to go on OK, so I just opened - marked as a draft, waiting for your magic patch.
The API of is easy to learn from , which makes it technically simple to use MuseSampler without MuseScore. For example, someone writing a VST plugin could just load and use it as a virtual instrument player in any DAW, without MuseScore. I guess that Muse Sounds authors wanted it to be tied to MuseScore, so they made it fail to initialize when loaded into a program with a different name. This is particularly clever against VSTs since a VST can't change argv0 - the user of such a plugin would have to rename their DAW to !
Wow, thank you so much for the debugging efforts you did! I'm available to do some testing if you need any.
Thanks! You are welcome to test

ln -s $out/Applications/mscore.app/Contents/MacOS/mscore $out/bin/mscore ''; <ins> # muse-sounds-manager installs Muse Sounds sampler libMuseSamplerCoreLib.so. # It requires that argv0 of the calling process ends with "/mscore" or "/MuseScore-4". # We need to ensure this in two cases: # # 1) when the user invokes MuseScore as "mscore" on the command line or from #    the .desktop file, and the normal argv0 is "mscore" (no "/"); # 2) when MuseScore invokes itself via File -> New, and the normal argv0 is #    the target of /proc/self/exe, which in Nixpkgs was "{...}/.mscore-wrapped" # # In order to achieve (2) we install the final binary as $out/libexec/mscore, and # in order to achieve (1) we use makeWrapper without --inherit-argv0. # # wrapQtAppsHook uses wrapQtApp -> wrapProgram -> makeBinaryWrapper --inherit-argv0 # so we disable it and explicitly use makeQtWrapper. # # TODO: check if something like this is also needed for macOS. dontWrapQtApps = stdenv.isLinux; postFixup = lib.optionalString stdenv.isLinux '' mkdir -p $out/libexec mv $out/bin/mscore $out/libexec makeQtWrapper $out/libexec/mscore $out/bin/mscore ''; </ins> # Don't run bundled upstreams tests, as they require a running X window system. doCheck = false;


Question:
(///) packaged in does not detect Muse Sounds Manager. The Muse Sounds profile is greyed out and cannot be used; leaving only MuseScore Basic available to use. Steps to reproduce the behavior: from (at the time of updating, version ) the unofficially packaged ) flake. MuseScore either from the desktop entry or via in a terminal, visit in the top bar, to check for available playback sounds to use. The Muse Sounds profile should be available to use and not greyed out. ! I have acknowledged the fact that although the mentioned Muse Sounds Manager package is unofficially packaged, the package works with the AppImage Version of MuseScore (packaged officially ), so I don't think this is the problem with the Muse Sounds Manager flake. Below is the screenshot of what the Playback Setup window should look like, taken from the AppImage version while opening the same score as the previous screenshot. ! I have tried reinstalling Muse Sounds Manager itself and reinstalling each Muse Sounds, but the issue persists. My entire system configuration files are . <!-- 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]:
Sorry, miss-clicked submitting the issue without adding any information. It'll be updated soon and reopened later.
Hey I'm sorry but I can't reproduce your issue. I Ran and downloaded an example font, and with both 4.3.0 and 4.3.1 I get: ! Before I downloaded the sound fonts I also had that button grayed out. Maybe you simply need to check again?
Thank you for responding. The issue persists after I've tried and and everything else (reinstalling MuseScore, Muse Sounds Manager, reinstalling all combinations of Muse Sounds) again to confirm that this is not an isolated incident. Additionally, I've compared the logs of both the AppImage version and the version. Most of both outputs are identical (apart from some timestamp-dependent data), but these lines only show up on the version: If necessary, please let me know how I can provide any more information.
Nice! Perhaps it is related to specific sound files you downloaded with that I didn't? Perhaps can you share all those? I have only this one named .
I've tried and downloaded all Muse Sounds from the beginning again for another time just for good measure. Here's an exact order of what I've tried (only one at a time, uninstalling all other Muse Sounds) and the issue still persists: Keys Brass Guitars Vol. 1 Choir Harp Percussion Strings Woodwinds So, all of the Muse Sounds available. The terminal logs print out the same error message on the version. I've also tried each of these with the AppImage version and I can confirm all of these are recognised with no issues. Is this in some ways related to how ? (This is an uneducated guess from me noticing logs mentioning the dynamic library )
Hey and sorry it took me a while to get back to this. It'd be nice to get your approval upon the 4.3.2 version bump (haven't even built it yet): So I tried to download all of the sounds mentioned above, and still I can see the muse sounds profile... I don't know what else I can suggest to debug this :/ Wait where do you see these lines? I don't see them in either muse-sounds-manager's logs nor in Musescore's ... Log of muse-sounds-manager-nix : And log of Musescore:
It's all good :) I'm just happy someone is even looking into this, to begin with. As to the 4.3.2 version bump, what do you need my approval of specifically? I'm sorry, I'm still very unfamiliar with the Nix ecosystem as a whole. Although, I have built the 4.3.2 on my machine and tried , everything seems to work (I've tried playing some tracks, editing them, etc), including the Muse Sounds. ! Additionally, I've done some more debugging: It seems like: running in the terminal (tested with + ) doing and then in the terminal (tested with & ) launching from the Desktop Entry all had the issue of Muse Sounds not being available to use. However, doing: (in ) / (in ) , into the output directory, then do all have Muse Sounds available to use. So this seems to be more of an issue with my shell environment somehow, and I honestly have no clue why this is the case, or where to start looking. That's a bummer. I mean, I guess I could always just use the AppImage version; It's not a big deal. Thank you for looking into it at least. Honestly, it could just be something arbitrary only in my machine in particular. Sorry, I should've clarified: The logs I sent earlier are from MuseScore (I just ran in the terminal). I didn't share Muse Sounds Manager's logs since nothing seems out of place there. Here's the full logs of me only running in the terminal and then closing the MuseScore window shortly afterwards: As you can see, line 9~12 showed the error I mentioned earlier. Again, thank you for taking your time looking into this.
Indeed this line seems suspicious.. And when you run version 4.3.2 you don't see it? I didn't find that line in my logs as well...
Yes, all other mentioned methods with Muse Sounds available don't have those errors in the logs.
It's weird because returns nothing... There is: Which may be related.
Edit: I was mistaken, setting the still doesn't detect Muse Sounds.
Yes it surprised you wrote initially it worked for you. We are on NixOS after all :). I'm not sure if you are subscribed to that issue or not, but I asked them about the source of .
BTW today I experienced crashing for me, and I checked the backtrace () and this is what I found: Interestingly: So indeed this issue is related to external shared objects that are not compatible with NixOS. I'm still a bit confused as to why in your case it doesn't necessarily crash, and instead it silently fails and you don't see the muse sounds... It'd be interesting to try to that file before you run ... In anycase, this should also be discussed with .
Hello, I've done some additional testing. It's not much, but I still want to tell you what I've found. It turns out these only work with that one MuseScore instance. From that instance, if I do or , it will always fail to load the dynamic library. I haven't yet figured out how to launch the new instance and have the dynamic library properly loaded. So this must be something weird about my variables, some directory mismatch, or something else. I've already sent my here, but in case you haven't taken a look, I have in it (which in turn makes return ), in case there are some hard-coded paths that don't respect this nix setting and is messing up with the dynamic library lookup. Just bringing it up since there have been some Nix packages not respecting that setting and causing issues with me in the past.
Hey did you end up finding a solution to this? I'm experiencing the exact same thing, and this thread is the only place mentioning these issues
Unfortunately, no, I haven't. Whenever I need to use MuseScore with MuseSounds (which is, all of the time), I launch MuseScore by doing in the terminal, which is one of the workarounds I've stated which have MuseSounds working.
Alright, thanks! Yeah I've seen your comment above, and to my surprise did indeed work. Maybe I'll just overwrite the mscore.desktop file with this command for now (Btw, thanks for the debugging effort you've put tinto this)
is not an issue due to the way library lookup works on Linux. Since is an optional dependency, it is loaded with (in via ), and says in particular that dependencies of such libraries are looked up in directories of the executable that calls . is a C++ application, so it also depends on and its contains a /nix/store directory with , and when it loads , the latter uses the same from the nix store. You can run to confirm that it has and that its contains the directory where it is located ()
The reason , etc. do not load is that the latter contains a shady function that prevents this library from loading when the calling process name () does not end with or . When you run MuseScore in the console from PATH, the process name is simply (without ), and the library declines to load. Similarly when you open a new score from MuseScore, it launches another instance of the program with the name which also does not end with .
the f. Amazing job figuring that out! (And also thanks for the MuseSounds nixpkgs PR )
Indeed this is a very impressive investigation and conclusion . I'm a bit confused though - whether we use a wrapper or not shouldn't make a difference right? Because the wrapper script (whether it is or ) always set to right - hence the shady function will return , at least as a of right? I wonder whether we should perform a to an absolute path in to improve 's experience described here.
I have already made a fix and will make a PR out of it very soon. MuseScore's argv0 will always end with regardless of the way it is launched, so can stay the same. (In my experience during system upgrades .desktop files are more convenient without absolute paths.)
You are right about the initial launch of MuseScore, but when you use File -New, it launches another copy of MuseScore, and it does this (as is common on Linux) by executing the target of , which is and this becomes of the new instance of MuseScore.
That's my experience as well. Ah wow, now I understand! Thanks. It means the patch will be much more involved... Good luck with that! I wonder why upstream decided to add that "check argv[0]` in the first place. The 4.4.2 release just came out, and the build locally seem to go on OK, so I just opened - marked as a draft, waiting for your magic patch.
The API of is easy to learn from , which makes it technically simple to use MuseSampler without MuseScore. For example, someone writing a VST plugin could just load and use it as a virtual instrument player in any DAW, without MuseScore. I guess that Muse Sounds authors wanted it to be tied to MuseScore, so they made it fail to initialize when loaded into a program with a different name. This is particularly clever against VSTs since a VST can't change argv0 - the user of such a plugin would have to rename their DAW to !
Wow, thank you so much for the debugging efforts you did! I'm available to do some testing if you need any.
Thanks! You are welcome to test

description = "Music notation and composition software"; homepage = "https://musescore.org/"; license = licenses.gpl3Only; <del> maintainers = with maintainers; [ vandenoever doronbehar ]; </del> <ins> maintainers = with maintainers; [ vandenoever doronbehar orivej ]; </ins> mainProgram = "mscore"; platforms = platforms.unix; };


Question: Project description for python! <!-- Describe the project a little: --It is built in reference with offical except it's color quantization part, which is based on thanks to . Metadata homepage URL: source URL: license: mit platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

<ins> { lib, buildPythonPackage, fetchurl, fetchPypi, setuptools, pybind11, requests, rich, pillow, }: let test-image = fetchurl { name = "test-image.jpg"; url = "https://unsplash.com/photos/u9tAl8WR3DI/download"; hash = "sha256-shGNdgOOydgGBtl/JCbTJ0AYgl+2xWvCgHBL+bEoTaE="; }; in buildPythonPackage rec { pname = "materialyoucolor"; version = "2.0.9"; pyproject = true; # PyPI sources contain additional vendored sources src = fetchPypi { inherit pname version; hash = "sha256-J35//h3tWn20f5ej6OXaw4NKnxung9q7m0E4Zf9PUw4="; }; build-system = [ setuptools pybind11 ]; nativeCheckInputs = [ requests rich pillow ]; checkPhase = '' runHook preCheck python tests/test_all.py ${test-image} 1 runHook postCheck ''; pythonImportsCheck = [ "materialyoucolor" "materialyoucolor.quantize" # ext ]; meta = { description = "Material You color generation algorithms in python"; homepage = "https://github.com/T-Dynamos/materialyoucolor-python"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ tomasajt ]; }; } </ins>


Question: Project description for python! <!-- Describe the project a little: --It is built in reference with offical except it's color quantization part, which is based on thanks to . Metadata homepage URL: source URL: license: mit platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

materialx = callPackage ../development/python-modules/materialx { }; <ins> materialyoucolor = callPackage ../development/python-modules/materialyoucolor { }; </ins> matchpy = callPackage ../development/python-modules/matchpy { }; mathlibtools = callPackage ../development/python-modules/mathlibtools { };


Question:
When bulding an lxc template with and the , the ping binary does not work as the not root user, giving: Steps to reproduce the behavior: my config repo: the nix-secrets input (private repo). `nix build .#proxmox the resulting tarball and upload to proxmox as an lxc template a container based on the template in (without nix-secrets repo, password is 'nixos') and attempt to run ping. The ping binary successfully pings something. the Home-manager systemd service also fails, but that might be a separate bug, reported Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
on NixOS 22.11: On NixOS 24.05: Seems to have been broken by I'll spend some time over the weekend to see what the best way to solve this issue is.

hostName = mkIf (!cfg.manageHostName) (mkForce ""); }; <ins> # unprivileged LXCs can't set net.ipv4.ping_group_range security.wrappers.ping = mkIf (!cfg.privileged) { owner = "root"; group = "root"; capabilities = "cap_net_raw+p"; source = "${pkgs.iputils.out}/bin/ping"; }; </ins> services.openssh = { enable = mkDefault true; startWhenNeeded = mkDefault true;


Question: Package name: gruvbox-gtk-theme Latest released version: unstable-2024-06-12 <!-- Search your package here: --- Current version on the unstable channel: unstable-2023-05-28 Current version on the stable/release channel: unstable-2023-05-28 <!-- 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]:

<del> { lib , stdenvNoCC , fetchFromGitHub , gnome-themes-extra , gtk-engine-murrine </del> <ins> { lib, stdenvNoCC, fetchFromGitHub, gnome-themes-extra, gtk-engine-murrine, </ins> }: stdenvNoCC.mkDerivation { pname = "gruvbox-gtk-theme"; <del> version = "unstable-2023-05-28"; </del> <ins> version = "0-unstable-2024-06-12"; </ins> src = fetchFromGitHub { owner = "Fausto-Korpsvart"; repo = "Gruvbox-GTK-Theme"; <del> rev = "c0b7fb501938241a3b6b5734f8cb1f0982edc6b4"; hash = "sha256-Y+6HuWaVkNqlYc+w5wLkS2LpKcDtpeOpdHnqBmShm5Q="; </del> <ins> rev = "1a0f6672283e1846ec307addd4647f2daad29402"; hash = "sha256-bbL4bHAdkmReogUQML9sMpSallZ7wrgbK3R64xiAYRo="; </ins> }; <del> propagatedUserEnvPkgs = [ gtk-engine-murrine ]; </del> <ins> propagatedUserEnvPkgs = [ gtk-engine-murrine ]; </ins> <del> buildInputs = [ gnome-themes-extra ]; </del> <ins> buildInputs = [ gnome-themes-extra ]; </ins> dontBuild = true;


Question: Package name: gruvbox-gtk-theme Latest released version: unstable-2024-06-12 <!-- Search your package here: --- Current version on the unstable channel: unstable-2023-05-28 Current version on the stable/release channel: unstable-2023-05-28 <!-- 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]:

runHook postInstall ''; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "Gtk theme based on the Gruvbox colour pallete"; homepage = "https://www.pling.com/p/1681313/"; <del> license = licenses.gpl3Only; platforms = platforms.unix; maintainers = [ maintainers.math-42 ]; </del> <ins> license = lib.licenses.gpl3Only; platforms = lib.platforms.unix; maintainers = with lib.maintainers; [ luftmensch-luftmensch math-42 ]; </ins> }; }


Question:
Decoders fail to load due to . Steps to reproduce the behavior: Working Module Imports (no ) Working decoders Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can you check if the above PR fixes the issue. I'm not able to test it right now as I don't have access to a DSLogic device ATM.
I'm unable to test the PR ATM, but the issue didn't require any device to be attached. Just install and run DSView as per bug report.
Ok just running and playing around did work for me after the update.
Hey, I checked this on my box, and I don't seem to be able to reproduce this issue, decoders seem to work for me when trying the demo device.

{ stdenv, lib, fetchFromGitHub, pkg-config, cmake, wrapQtAppsHook <del> , libzip, boost, fftw, qtbase, qtwayland, qtsvg, libusb1 </del> <ins> , libzip, boost, fftw, libusb1, qtbase, qtsvg, qtwayland </ins> , python3, desktopToDarwinBundle }: stdenv.mkDerivation rec { pname = "dsview"; <del> version = "1.3.1"; </del> <ins> version = "1.3.2"; </ins> src = fetchFromGitHub { owner = "DreamSourceLab"; repo = "DSView"; rev = "v${version}"; <del> sha256 = "sha256-LwrlB+Nwq34YjwGmnbUWS3W//ZHr8Do2Wf2te+2oBeI="; </del> <ins> sha256 = "sha256-d/TfCuJzAM0WObOiBhgfsTirlvdROrlCm+oL1cqUrIs="; </ins> }; patches = [


Question:
Decoders fail to load due to . Steps to reproduce the behavior: Working Module Imports (no ) Working decoders Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can you check if the above PR fixes the issue. I'm not able to test it right now as I don't have access to a DSLogic device ATM.
I'm unable to test the PR ATM, but the issue didn't require any device to be attached. Just install and run DSView as per bug report.
Ok just running and playing around did work for me after the update.
Hey, I checked this on my box, and I don't seem to be able to reproduce this issue, decoders seem to work for me when trying the demo device.

dropbear = callPackage ../tools/networking/dropbear { }; <del> dsview = qt6Packages.callPackage ../applications/science/electronics/dsview { }; </del> <ins> dsview = libsForQt5.callPackage ../applications/science/electronics/dsview { }; </ins> dtach = callPackage ../tools/misc/dtach { };


Question:
btrfs-assistant failed to use in nix-shell Steps to reproduce the behavior: A clear and concise description of what you expected to happen. nix-shell should success <!-- 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]:
I fixed the nix-shell -p error but the application doesn't run properly. Looking into if we need to do some env variable nonsense because of the way the application works.

<del> { lib , stdenv , fetchFromGitLab , bash , btrfs-progs , cmake , coreutils , git , pkg-config , qt6 , snapper , util-linux , enableSnapper ? true , nix-update-script </del> <ins> { lib, stdenv, fetchFromGitLab, bash, btrfs-progs, cmake, coreutils, git, pkg-config, qt6, snapper, util-linux, enableSnapper ? true, nix-update-script, </ins> }: stdenv.mkDerivation (finalAttrs: {


Question:
btrfs-assistant failed to use in nix-shell Steps to reproduce the behavior: A clear and concise description of what you expected to happen. nix-shell should success <!-- 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]:
I fixed the nix-shell -p error but the application doesn't run properly. Looking into if we need to do some env variable nonsense because of the way the application works.

cmake git pkg-config <ins> qt6.wrapQtAppsHook </ins> ]; buildInputs = [ btrfs-progs <ins> coreutils </ins> qt6.qtbase qt6.qtsvg qt6.qttools qt6.qtwayland <del> ]; propagatedBuildInputs = [ qt6.wrapQtAppsHook ]; </del> <ins> util-linux ] ++ lib.optionals enableSnapper [ snapper ]; </ins> <del> prePatch = '' substituteInPlace src/util/System.cpp  --replace '/bin/bash' "${lib.getExe bash}" '' + lib.optionalString enableSnapper '' substituteInPlace src/main.cpp  --replace '/usr/bin/snapper' "${lib.getExe snapper}" ''; </del> <ins> prePatch = '' substituteInPlace src/util/System.cpp  --replace-fail '/bin/bash' "${lib.getExe bash}" </ins> <del> postPatch = '' substituteInPlace src/org.btrfs-assistant.pkexec.policy  --replace '/usr/bin' "$out/bin" </del> <ins> substituteInPlace src/main.cpp  --replace-fail 'if (!qEnvironmentVariableIsEmpty("DISPLAY"))' ' if(!qEnvironmentVariableIsEmpty("DISPLAY") || !qEnvironmentVariableIsEmpty("WAYLAND_DISPLAY"))' '' + lib.optionalString enableSnapper '' substituteInPlace src/main.cpp  --replace-fail '/usr/bin/snapper' "${lib.getExe snapper}" ''; </ins> <del> substituteInPlace src/btrfs-assistant  --replace 'btrfs-assistant-bin' "$out/bin/btrfs-assistant-bin" </del> <ins> postPatch = '' substituteInPlace src/org.btrfs-assistant.pkexec.policy  --replace-fail '/usr/bin' "$out/bin" </ins> <del> substituteInPlace src/btrfs-assistant-launcher  --replace 'btrfs-assistant' "$out/bin/btrfs-assistant" '' + lib.optionalString enableSnapper '' substituteInPlace src/btrfs-assistant.conf  --replace '/usr/bin/snapper' "${lib.getExe snapper}" ''; </del> <ins> substituteInPlace src/btrfs-assistant  --replace-fail 'btrfs-assistant-bin' "$out/bin/btrfs-assistant-bin" </ins> <del> qtWrapperArgs = let runtimeDeps = lib.makeBinPath ([ coreutils util-linux ] ++ lib.optionals enableSnapper [ snapper ]); in [ "--prefix PATH : ${runtimeDeps}" ]; </del> <ins> substituteInPlace src/btrfs-assistant-launcher  --replace-fail 'btrfs-assistant' "$out/bin/btrfs-assistant" '' + lib.optionalString enableSnapper '' substituteInPlace src/btrfs-assistant.conf  --replace-fail '/usr/bin/snapper' "${lib.getExe snapper}" ''; </ins> passthru.updateScript = nix-update-script { };


Question: Steps to reproduce the behavior: Discovered via the Nixpkgs LLVM Workspace project. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --No maintainers, CC last person who touched Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

esac done <del> if $needsTarget; then </del> <ins> if $needsTarget && [[ $0 != *cpp ]]; then </ins> extraBefore+=(-target @defaultTarget@ @machineFlags@) fi


Question: Steps to reproduce the behavior: Discovered via the Nixpkgs LLVM Workspace project. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --No maintainers, CC last person who touched Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

libX11 = super.libX11.overrideAttrs (attrs: { outputs = [ "out" "dev" "man" ]; configureFlags = attrs.configureFlags or [] <del> ++ malloc0ReturnsNullCrossFlag; </del> <ins> ++ malloc0ReturnsNullCrossFlag ++ lib.optional (stdenv.targetPlatform.useLLVM or false) "ac_cv_path_RAWCPP=cpp"; </ins> depsBuildBuild = [ buildPackages.stdenv.cc ] ++ lib.optionals stdenv.hostPlatform.isStatic [


Question:
Steps to reproduce the behavior: Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Maybe we should just wait and see whether 2024.02 also has the same problem (that should be around the corner, see ) For now rolling back to to get unstuck.
I'm skeptical about IDEA 2024.2 would use JRE 21, as in the following comment From https://intellij-

let <del> jbr = jetbrains.jdk-no-jcef; </del> <ins> jbr = jetbrains.jdk-no-jcef-17; </ins> ideaSrc = fetchFromGitHub { owner = "jetbrains";


Question:
Steps to reproduce the behavior: Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Maybe we should just wait and see whether 2024.02 also has the same problem (that should be around the corner, see ) For now rolling back to to get unstuck.
I'm skeptical about IDEA 2024.2 would use JRE 21, as in the following comment From https://intellij-

<ins> { lib , stdenv , fetchFromGitHub , jetbrains , openjdk17 , openjdk17-bootstrap , git , autoconf , unzip , rsync , debugBuild ? false , withJcef ? true , libXdamage , libXxf86vm , libXrandr , libXi , libXcursor , libXrender , libX11 , libXext , libxcb , nss , nspr , libdrm , mesa , wayland , udev }: assert debugBuild -> withJcef; let arch = { "aarch64-linux" = "aarch64"; "x86_64-linux" = "x64"; }.${stdenv.hostPlatform.system} or (throw "Unsupported system: ${stdenv.hostPlatform.system}"); cpu = stdenv.hostPlatform.parsed.cpu.name; in openjdk17.overrideAttrs (oldAttrs: rec { pname = "jetbrains-jdk" + lib.optionalString withJcef "-jcef"; javaVersion = "17.0.11"; build = "1207.24"; # To get the new tag: # git clone https://github.com/jetbrains/jetbrainsruntime # cd jetbrainsruntime # git reset --hard [revision] # git log --simplify-by-decoration --decorate=short --pretty=short | grep "jbr-" --color=never | cut -d "(" -f2 | cut -d ")" -f1 | awk '{print $2}' | sort -t "-" -k 2 -g | tail -n 1 | tr -d "," openjdkTag = "jbr-17.0.8+7"; version = "${javaVersion}-b${build}"; src = fetchFromGitHub { owner = "JetBrains"; repo = "JetBrainsRuntime"; rev = "jb${version}"; hash = "sha256-a7cJF2iCW/1GK0/GmVbaY5pYcn3YtZy5ngFkyAGRhu0="; }; BOOT_JDK = openjdk17-bootstrap.home; # run `git log -1 --pretty=%ct` in jdk repo for new value on update SOURCE_DATE_EPOCH = 1715809405; patches = [ ]; dontConfigure = true; buildPhase = '' runHook preBuild ${lib.optionalString withJcef "cp -r ${jetbrains.jcef} jcef_linux_${arch}"} sed  -e "s/OPENJDK_TAG=.*/OPENJDK_TAG=${openjdkTag}/"  -e "s/SOURCE_DATE_EPOCH=.*//"  -e "s/export SOURCE_DATE_EPOCH//"  -i jb/project/tools/common/scripts/common.sh sed -i "s/STATIC_CONF_ARGS/STATIC_CONF_ARGS $configureFlags/" jb/project/tools/linux/scripts/mkimages_${arch}.sh sed  -e "s/create_image_bundle "jb/#/"  -e "s/echo Creating /exit 0 #/"  -i jb/project/tools/linux/scripts/mkimages_${arch}.sh patchShebangs . ./jb/project/tools/linux/scripts/mkimages_${arch}.sh ${build} ${if debugBuild then "fd" else (if withJcef then "jcef" else "nomod")} runHook postBuild ''; installPhase = let buildType = if debugBuild then "fastdebug" else "release"; debugSuffix = if debugBuild then "-fastdebug" else ""; jcefSuffix = if debugBuild || !withJcef then "" else "_jcef"; jbrsdkDir = "jbrsdk${jcefSuffix}-${javaVersion}-linux-${arch}${debugSuffix}-b${build}"; in '' runHook preInstall mv build/linux-${cpu}-server-${buildType}/images/jdk/man build/linux-${cpu}-server-${buildType}/images/${jbrsdkDir} rm -rf build/linux-${cpu}-server-${buildType}/images/jdk mv build/linux-${cpu}-server-${buildType}/images/${jbrsdkDir} build/linux-${cpu}-server-${buildType}/images/jdk '' + oldAttrs.installPhase + "runHook postInstall"; postInstall = lib.optionalString withJcef '' chmod +x $out/lib/openjdk/lib/chrome-sandbox ''; dontStrip = debugBuild; postFixup = '' # Build the set of output library directories to rpath against LIBDIRS="${lib.makeLibraryPath [ libXdamage libXxf86vm libXrandr libXi libXcursor libXrender libX11 libXext libxcb nss nspr libdrm mesa wayland udev ]}" for output in $outputs; do if [ "$output" = debug ]; then continue; fi LIBDIRS="$(find $(eval echo $$output) -name *.so* -exec dirname {} + | sort -u | tr 'n' ':'):$LIBDIRS" done # Add the local library paths to remove dependencies on the bootstrap for output in $outputs; do if [ "$output" = debug ]; then continue; fi OUTPUTDIR=$(eval echo $$output) BINLIBS=$(find $OUTPUTDIR/bin/ -type f; find $OUTPUTDIR -name *.so*) echo "$BINLIBS" | while read i; do patchelf --set-rpath "$LIBDIRS:$(patchelf --print-rpath "$i")" "$i" || true patchelf --shrink-rpath "$i" || true done done ''; nativeBuildInputs = [ git autoconf unzip rsync ] ++ oldAttrs.nativeBuildInputs; meta = with lib; { description = "An OpenJDK fork to better support Jetbrains's products."; longDescription = '' JetBrains Runtime is a runtime environment for running IntelliJ Platform based products on Windows, Mac OS X, and Linux. JetBrains Runtime is based on OpenJDK project with some modifications. These modifications include: Subpixel Anti-Aliasing, enhanced font rendering on Linux, HiDPI support, ligatures, some fixes for native crashes not presented in official build, and other small enhancements. JetBrains Runtime is not a certified build of OpenJDK. Please, use at your own risk. ''; homepage = "https://confluence.jetbrains.com/display/JBR/JetBrains+Runtime"; inherit (openjdk17.meta) license platforms mainProgram; maintainers = with maintainers; [ edwtjo ]; broken = stdenv.isDarwin; }; passthru = oldAttrs.passthru // { home = "${jetbrains.jdk}/lib/openjdk"; }; }) </ins>


Question:
Steps to reproduce the behavior: Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Maybe we should just wait and see whether 2024.02 also has the same problem (that should be around the corner, see ) For now rolling back to to get unstuck.
I'm skeptical about IDEA 2024.2 would use JRE 21, as in the following comment From https://intellij-

jdk = jdk21; withJcef = false; }; <ins> jdk-no-jcef-17 = callPackage ../development/compilers/jetbrains-jdk/17.nix { withJcef = false; }; </ins> jdk = callPackage ../development/compilers/jetbrains-jdk { jdk = jdk21; };


Question: Package name: Latest released version: 1.9.0 Current version on the unstable channel: 1.7.0 Current version on the stable/release channel: 1.2.0 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

PRODUCTION = "true"; ALEMBIC_CONFIG_FILE="${pkg}/config/alembic.ini"; API_PORT = toString cfg.port; <del> BASE_URL = "http://localhost:${cfg.port}"; </del> <ins> BASE_URL = "http://localhost:${toString cfg.port}"; </ins> DATA_DIR = "/var/lib/mealie"; CRF_MODEL_PATH = "/var/lib/mealie/model.crfmodel"; } // (builtins.mapAttrs (_: val: toString val) cfg.settings);


Question: Package name: Latest released version: 1.9.0 Current version on the unstable channel: 1.7.0 Current version on the stable/release channel: 1.2.0 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

}: let <del> version = "1.7.0"; </del> <ins> version = "1.9.0"; </ins> src = fetchFromGitHub { owner = "mealie-recipes"; repo = "mealie"; rev = "v${version}"; <del> hash = "sha256-z7kLBDzvzPWY7XmpROMpw3LcDpsl+hA+w1SdhrD/yNU="; </del> <ins> hash = "sha256-gg7ClclBS9j9n4/3HLxbX8HXTz9Zw5+BYG2MEYRsRBU="; </ins> }; frontend = callPackage (import ./mealie-frontend.nix src version) { };


Question:
The package is broken, , because it fails during on Darwin. I am uncertain if this is something that has to be fixed in , or can it be worked around in nixpkgs? Steps to reproduce the behavior: Build on macOS <!-- 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]:
can you help out here?

hash = "sha256-rMbf09pCHvVYI9g/aq74+PcsuU2LezpmDz4b/w9vRyc="; }; <ins> postPatch = lib.optionalString stdenv.isDarwin '' substituteInPlace setup.py  --replace-fail "-flto" "" ''; </ins> nativeBuildInputs = [ pybind11 ]; # tests are removed from fork


Question:
The package is broken, , because it fails during on Darwin. I am uncertain if this is something that has to be fixed in , or can it be worked around in nixpkgs? Steps to reproduce the behavior: Build on macOS <!-- 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]:
can you help out here?

homepage = "https://github.com/searxng/fasttext-predict/"; license = licenses.mit; maintainers = with maintainers; [ SuperSandro2000 ]; <del> # ImportError: dynamic module does not define module export function (PyInit_fasttext_pybind) broken = stdenv.isDarwin; </del> }; }


Question:
There is Bitwig1 and Bitwig2. I for example have only a license for Bitwig1. And I will not pay frequently for features I don't use (because I'm not a professional musican). Right now I use the overrideAttrs to install bitwig1, but it would be smarter to provide an older version as well (most likely there will be a bitwig3 someday). I could create a pull-request, just wanted to open a quick discussion first, because I'm new to NixOs and maybe there is already a very smart thing that makes live much simpler, which I'm not aware.
See . I think we shouldn't distribute paid updates for proprietary software under the same attribute without a way to opt out (other than rollback), this heavily breaks reverse compatibility. I think that should point to the latest version, with and pointing to specific major versions. Derivation for 2.x branch may override 1.x, since it has same dependencies and layout, the only difference is additional dependency on :

<ins> { stdenv, fetchurl, alsaLib, bzip2, cairo, dpkg, freetype, gdk_pixbuf , glib, gtk2, harfbuzz, jdk, lib, xorg , libbsd, libjack2, libpng , libxkbcommon , makeWrapper, pixman , xdg_utils, zenity, zlib }: stdenv.mkDerivation rec { name = "bitwig-studio-${version}"; version = "1.3.16"; src = fetchurl { url    = "https://downloads.bitwig.com/stable/${version}/bitwig-studio-${version}.deb"; sha256 = "0n0fxh9gnmilwskjcayvjsjfcs3fz9hn00wh7b3gg0cv3qqhich8"; }; nativeBuildInputs = [ dpkg makeWrapper ]; unpackCmd = "mkdir root ; dpkg-deb -x $curSrc root"; dontBuild    = true; dontPatchELF = true; dontStrip    = true; libPath = with xorg; lib.makeLibraryPath [ alsaLib bzip2.out cairo freetype gdk_pixbuf glib gtk2 harfbuzz libX11 libXau libXcursor libXdmcp libXext libXfixes libXrender libbsd libjack2 libpng libxcb libxkbfile pixman xcbutil xcbutilwm zlib ]; binPath = lib.makeBinPath [ xdg_utils zenity ]; installPhase = '' mkdir -p $out cp -r opt/bitwig-studio $out/libexec # Use NixOS versions of these libs instead of the bundled ones. ( cd $out/libexec/lib/bitwig-studio rm libbz2.so* libxkbfile.so* libXcursor.so* libXau.so*  libXdmcp.so* libpng16.so* libxcb*.so* libharfbuzz.so*  libcairo.so* libfreetype.so* ln -s ${bzip2.out}/lib/libbz2.so.1.0.6 libbz2.so.1.0 ) # Use our OpenJDK instead of Bitwig’s bundled—and commercial!—one. rm -rf $out/libexec/lib/jre ln -s ${jdk.home}/jre $out/libexec/lib/jre # Bitwig’s `libx11-windowing-system.so` has several problems: # #   • has some old version of libxkbcommon linked statically (ಠ_ಠ), # #   • hardcodes path to `/usr/share/X11/xkb`, # #   • even if we redirected it with libredirect (after adding #     `eaccess()` to libredirect!), their version of libxkbcommon #     is unable to parse our xkeyboardconfig. Been there, done that. # # However, it suffices to override theirs with our libxkbcommon # in LD_PRELOAD. :-) find $out -type f -executable  -not -name '*.so.*'  -not -name '*.so'  -not -path '*/resources/*' |  while IFS= read -r f ; do patchelf  --set-interpreter $(cat ${stdenv.cc}/nix-support/dynamic-linker)  $f &&  wrapProgram $f  --prefix PATH : "${binPath}"  --prefix LD_LIBRARY_PATH : "${libPath}"  --set LD_PRELOAD "${libxkbcommon.out}/lib/libxkbcommon.so" || true done mkdir -p $out/bin ln -s $out/libexec/bitwig-studio $out/bin/bitwig-studio cp -r usr/share $out/share substitute usr/share/applications/bitwig-studio.desktop  $out/share/applications/bitwig-studio.desktop  --replace /usr/bin/bitwig-studio $out/bin/bitwig-studio ''; meta = with stdenv.lib; { description = "A digital audio workstation"; longDescription = '' Bitwig Studio is a multi-platform music-creation system for production, performance and DJing, with a focus on flexible editing tools and a super-fast workflow. ''; homepage = http://www.bitwig.com/; license = licenses.unfree; platforms = [ "x86_64-linux" ]; maintainers = with maintainers; [ michalrus mrVanDalo ]; }; } </ins>


Question:
There is Bitwig1 and Bitwig2. I for example have only a license for Bitwig1. And I will not pay frequently for features I don't use (because I'm not a professional musican). Right now I use the overrideAttrs to install bitwig1, but it would be smarter to provide an older version as well (most likely there will be a bitwig3 someday). I could create a pull-request, just wanted to open a quick discussion first, because I'm new to NixOs and maybe there is already a very smart thing that makes live much simpler, which I'm not aware.
See . I think we shouldn't distribute paid updates for proprietary software under the same attribute without a way to opt out (other than rollback), this heavily breaks reverse compatibility. I think that should point to the latest version, with and pointing to specific major versions. Derivation for 2.x branch may override 1.x, since it has same dependencies and layout, the only difference is additional dependency on :

<ins> { stdenv, fetchurl, bitwig-studio1, xdg_utils, zenity, ffmpeg }: bitwig-studio1.overrideAttrs (oldAttrs: rec { name = "bitwig-studio-${version}"; version = "2.2.2"; src = fetchurl { url    = "https://downloads.bitwig.com/stable/${version}/bitwig-studio-${version}.deb"; sha256 = "1x4wka32xlygmhdh9rb15s37zh5qjrgap2qk35y34c52lf5aak22"; }; buildInputs = bitwig-studio1.buildInputs ++ [ ffmpeg ]; binPath = stdenv.lib.makeBinPath [ ffmpeg xdg_utils zenity ]; }) </ins>


Question:
There is Bitwig1 and Bitwig2. I for example have only a license for Bitwig1. And I will not pay frequently for features I don't use (because I'm not a professional musican). Right now I use the overrideAttrs to install bitwig1, but it would be smarter to provide an older version as well (most likely there will be a bitwig3 someday). I could create a pull-request, just wanted to open a quick discussion first, because I'm new to NixOs and maybe there is already a very smart thing that makes live much simpler, which I'm not aware.
See . I think we shouldn't distribute paid updates for proprietary software under the same attribute without a way to opt out (other than rollback), this heavily breaks reverse compatibility. I think that should point to the latest version, with and pointing to specific major versions. Derivation for 2.x branch may override 1.x, since it has same dependencies and layout, the only difference is additional dependency on :

<del> { stdenv, fetchurl, alsaLib, bzip2, cairo, dpkg, ffmpeg, freetype, gdk_pixbuf , glib, gtk2, harfbuzz, jdk, lib, libX11, libXau, libXcursor, libXdmcp , libXext, libXfixes, libXrender, libbsd, libjack2, libpng, libxcb , libxkbcommon, libxkbfile, makeWrapper, pixman, xcbutil, xcbutilwm , xdg_utils, zenity, zlib }: stdenv.mkDerivation rec { name = "bitwig-studio-${version}"; version = "2.2.2"; src = fetchurl { url = "https://downloads.bitwig.com/stable/${version}/bitwig-studio-${version}.deb"; sha256 = "1x4wka32xlygmhdh9rb15s37zh5qjrgap2qk35y34c52lf5aak22"; }; nativeBuildInputs = [ dpkg makeWrapper ]; unpackCmd = "mkdir root ; dpkg-deb -x $curSrc root"; dontBuild = true; dontPatchELF = true; dontStrip = true; libPath = lib.makeLibraryPath [ alsaLib bzip2.out cairo freetype gdk_pixbuf glib gtk2 harfbuzz libX11 libXau libXcursor libXdmcp libXext libXfixes libXrender libbsd libjack2 libpng libxcb libxkbfile pixman xcbutil xcbutilwm zlib ]; binPath = lib.makeBinPath [ ffmpeg xdg_utils zenity ]; installPhase = '' mkdir -p $out cp -r opt/bitwig-studio $out/libexec # Use NixOS versions of these libs instead of the bundled ones. ( cd $out/libexec/lib/bitwig-studio rm libbz2.so* libxkbfile.so* libXcursor.so* libXau.so*  libXdmcp.so* libpng16.so* libxcb*.so* libharfbuzz.so*  libcairo.so* libfreetype.so* ln -s ${bzip2.out}/lib/libbz2.so.1.0.6 libbz2.so.1.0 ) # Use our OpenJDK instead of Bitwig’s bundled—and commercial!—one. rm -rf $out/libexec/lib/jre ln -s ${jdk.home}/jre $out/libexec/lib/jre # Bitwig’s `libx11-windowing-system.so` has several problems: # #   • has some old version of libxkbcommon linked statically (ಠ_ಠ), # #   • hardcodes path to `/usr/share/X11/xkb`, # #   • even if we redirected it with libredirect (after adding #     `eaccess()` to libredirect!), their version of libxkbcommon #     is unable to parse our xkeyboardconfig. Been there, done that. # # However, it suffices to override theirs with our libxkbcommon # in LD_PRELOAD. :-) find $out -type f -executable  -not -name '*.so.*'  -not -name '*.so'  -not -path '*/resources/*' |  while IFS= read -r f ; do patchelf  --set-interpreter $(cat ${stdenv.cc}/nix-support/dynamic-linker)  $f &&  wrapProgram $f  --prefix PATH : "${binPath}"  --prefix LD_LIBRARY_PATH : "${libPath}"  --set LD_PRELOAD "${libxkbcommon.out}/lib/libxkbcommon.so" || true done mkdir -p $out/bin ln -s $out/libexec/bitwig-studio $out/bin/bitwig-studio cp -r usr/share $out/share substitute usr/share/applications/bitwig-studio.desktop  $out/share/applications/bitwig-studio.desktop  --replace /usr/bin/bitwig-studio $out/bin/bitwig-studio ''; meta = with stdenv.lib; { description = "A digital audio workstation"; longDescription = '' Bitwig Studio is a multi-platform music-creation system for production, performance and DJing, with a focus on flexible editing tools and a super-fast workflow. ''; homepage = http://www.bitwig.com/; license = licenses.unfree; platforms = [ "x86_64-linux" ]; maintainers = with maintainers; [ michalrus ]; }; } </del>


Question:
There is Bitwig1 and Bitwig2. I for example have only a license for Bitwig1. And I will not pay frequently for features I don't use (because I'm not a professional musican). Right now I use the overrideAttrs to install bitwig1, but it would be smarter to provide an older version as well (most likely there will be a bitwig3 someday). I could create a pull-request, just wanted to open a quick discussion first, because I'm new to NixOs and maybe there is already a very smart thing that makes live much simpler, which I'm not aware.
See . I think we shouldn't distribute paid updates for proprietary software under the same attribute without a way to opt out (other than rollback), this heavily breaks reverse compatibility. I think that should point to the latest version, with and pointing to specific major versions. Derivation for 2.x branch may override 1.x, since it has same dependencies and layout, the only difference is additional dependency on :

bitscope = callPackage ../applications/science/electronics/bitscope/packages.nix { }; <del> bitwig-studio =  callPackage ../applications/audio/bitwig-studio { </del> <ins> bitwig-studio1 =  callPackage ../applications/audio/bitwig-studio/bitwig-studio1.nix { </ins> inherit (gnome2) zenity; }; <ins> bitwig-studio2 =  callPackage ../applications/audio/bitwig-studio/bitwig-studio2.nix { inherit (gnome2) zenity; inherit (self) bitwig-studio1; }; bitwig-studio = bitwig-studio2; </ins> bgpdump = callPackage ../tools/networking/bgpdump { };


Question: The package for the Ares emulator doesn't seem to include Vulkan packages so it will return if you try to run a Nintendo 64 game. Other cores that don't use Vulkan are unaffected Steps to reproduce the behavior: Ares N64 game error in console glitched or black screen The game works ! see similar issue: Ares issue before I realized it was likely NixOS: GPU: RX 6800 Driver install setup: <!-- 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]:

, which , wrapGAppsHook3 , darwin <ins> , vulkan-loader , autoPatchelfHook </ins> }: stdenv.mkDerivation (finalAttrs: {


Question: The package for the Ares emulator doesn't seem to include Vulkan packages so it will return if you try to run a Nintendo 64 game. Other cores that don't use Vulkan are unaffected Steps to reproduce the behavior: Ares N64 game error in console glitched or black screen The game works ! see similar issue: Ares issue before I realized it was likely NixOS: GPU: RX 6800 Driver install setup: <!-- 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]:

]; nativeBuildInputs = [ <ins> autoPatchelfHook </ins> pkg-config which wrapGAppsHook3


Question: The package for the Ares emulator doesn't seem to include Vulkan packages so it will return if you try to run a Nintendo 64 game. Other cores that don't use Vulkan are unaffected Steps to reproduce the behavior: Ares N64 game error in console glitched or black screen The game works ! see similar issue: Ares issue before I realized it was likely NixOS: GPU: RX 6800 Driver install setup: <!-- 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]:

darwin.apple_sdk_11_0.frameworks.OpenAL ]; <ins> appendRunpaths = [ (lib.makeLibraryPath [ vulkan-loader ]) ]; </ins> enableParallelBuilding = true; makeFlags = lib.optionals stdenv.isLinux [


Question: Package name: quickemu Latest released version: 4.9.5 <!-- Search your package here: --- Current version on the unstable channel: 4.9.4 Current version on the stable/release channel: 4.9.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. --fedx- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

cdrtools, curl, gawk, <ins> glxinfo, </ins> gnugrep, gnused, jq,


Question: Package name: quickemu Latest released version: 4.9.5 <!-- Search your package here: --- Current version on the unstable channel: 4.9.4 Current version on the stable/release channel: 4.9.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. --fedx- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

quickemu, testers, installShellFiles, <del> fetchpatch2, </del> }: let runtimePaths = [


Question: Package name: quickemu Latest released version: 4.9.5 <!-- Search your package here: --- Current version on the unstable channel: 4.9.4 Current version on the stable/release channel: 4.9.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. --fedx- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

qemu socat swtpm <del> usbutils </del> util-linux unzip <del> xdg-user-dirs </del> xrandr zsync <ins> ] ++ lib.optionals stdenv.isLinux [ glxinfo usbutils xdg-user-dirs </ins> ]; in stdenv.mkDerivation (finalAttrs: { pname = "quickemu"; <del> version = "4.9.4-unstable-2024-05-28"; </del> <ins> version = "4.9.5"; </ins> src = fetchFromGitHub { owner = "quickemu-project"; repo = "quickemu"; <del> rev = "d78255b097b599e8ab3713cb61c4085cc45f5a95"; # TODO: return to version on next release hash = "sha256-fF306CdGqKM+779OLm0NNyqPBtm7TuU7UN/NanT12y8="; </del> <ins> rev = finalAttrs.version; hash = "sha256-UlpNujF2E8H1zcWTen8D29od60pY8FaGueviT0iwupQ="; </ins> }; postPatch = ''


Question: Package name: quickemu Latest released version: 4.9.5 <!-- Search your package here: --- Current version on the unstable channel: 4.9.4 Current version on the stable/release channel: 4.9.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. --fedx- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

''; passthru.tests = testers.testVersion { <del> version = "4.9.5"; # required for passing tests, TODO: remove when release bump </del> package = quickemu; }; meta = { description = "Quickly create and run optimised Windows, macOS and Linux virtual machines"; homepage = "https://github.com/quickemu-project/quickemu"; <ins> changelog = "https://github.com/quickemu-project/quickemu/releases/tag/${finalAttrs.version}"; </ins> mainProgram = "quickemu"; license = lib.licenses.mit; maintainers = with lib.maintainers; [


Question:
Specs-nvim does not work in Neovim 0.10 and the author has not updated the upstream version. The derivation should point to the updated fork instead: Steps to reproduce the behavior: specs-nvim with Neovim 0.10 specs-nvim errors Should I have used the out-of-date packaging report issue template instead? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
no pb for me. Feel free to submit a PR. Pinging as he might know better.
What does no pb mean? I'll make a PR
I guess that it means "go for it, let's switch to the fork".

specs-nvim = buildVimPlugin { pname = "specs.nvim"; <del> version = "2022-09-20"; </del> <ins> version = "2024-05-19"; </ins> src = fetchFromGitHub { <del> owner = "edluffy"; </del> <ins> owner = "cxwx"; </ins> repo = "specs.nvim"; <del> rev = "2743e412bbe21c9d73954c403d01e8de7377890d"; sha256 = "1ycqvxrn13bfimf9k03bmm1baml8gyq5lxqjxh1fya44s2bg714r"; </del> <ins> rev = "dd82496f538b688cedf98429f89fef47ecb0625e"; sha256 = "0427fx6iw3i2y9ny3sz1na32bxcj8i93dbm93ckxf3bii8zqjs0s"; </ins> }; <del> meta.homepage = "https://github.com/edluffy/specs.nvim/"; </del> <ins> meta.homepage = "https://github.com/cxwx/specs.nvim/"; </ins> }; spellsitter-nvim = buildVimPlugin {


Question:
Specs-nvim does not work in Neovim 0.10 and the author has not updated the upstream version. The derivation should point to the updated fork instead: Steps to reproduce the behavior: specs-nvim with Neovim 0.10 specs-nvim errors Should I have used the out-of-date packaging report issue template instead? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
no pb for me. Feel free to submit a PR. Pinging as he might know better.
What does no pb mean? I'll make a PR
I guess that it means "go for it, let's switch to the fork".

https://github.com/liuchengxu/space-vim/,, https://github.com/ctjhoa/spacevim/,, https://github.com/chrisgeo/sparkup/,, <del> https://github.com/edluffy/specs.nvim/,, </del> <ins> https://github.com/cxwx/specs.nvim/,HEAD, </ins> https://github.com/lewis6991/spellsitter.nvim/,HEAD, https://github.com/stsewd/sphinx.nvim/,, https://github.com/sjl/splice.vim/,,


Question: Package name: uutils-coreutils Latest released version: 0.0.27 <!-- Search your package here: --- Current version on the unstable channel: 0.0.25 Current version on the stable/release channel: 0.0.25 <!-- 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]:

stdenv.mkDerivation rec { pname = "uutils-coreutils"; <del> version = "0.0.25"; </del> <ins> version = "0.0.27"; </ins> src = fetchFromGitHub { owner = "uutils"; repo = "coreutils"; rev = version; <del> hash = "sha256-25jmlGxMWzAaJEmMHruA6H+nqx2QHnYX9c9SKqrQRE4="; </del> <ins> hash = "sha256-6MbX3C5NVwiOwXW5xJO2X3qKMh3pUSALR9aK2IbgaaU="; </ins> }; cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; <del> hash = "sha256-lQoOkiSga2aS8GNgLcHdid1/1u3johYEcGi9oOVsdJs="; </del> <ins> hash = "sha256-JowORfYHxN8GqvWeUm0ACnHNM3uZviYbhR7BOeAfphw="; </ins> }; nativeBuildInputs = [ rustPlatform.cargoSetupHook sphinx ];


Question: Xpra supports forwarding invocations from the server to the client. The Xpra client defaults to hardcoding as the command to invoke on the client, which does not exist in NixOS. This bug does not impact hosts other than NixOS. Steps to reproduce the behavior: somehow. The Xpra client should invoke the local . N/A. This could be fixed by setting the open command to just , but it might match the intent better to change it to something like perhaps. Presumably, the point of doing it this way is to avoid any other copies of that might appear on the , e.g. Xpra's own. I suppose we can't really rely on to exist: even if we could on NixOS, we can't on other Linux distributions running Nix, where might make more sense. It seems to me that the best compromise, then, is to hardcode a path to copy of and users can override this using the option if needed. The open command that Xpra uses is configurable on the client-side, but the default is set as a platform-specific variable. On Linux, it is set in . Because there are separate values for both Windows and Darwin hosts, patching the value to shouldn't ever break them (but of course it should still be a Linux-specific patch, otherwise it unnecessarily brings into the closure.) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

, pango , pulseaudio , python3 <ins> , stdenv </ins> , util-linux , which , x264 , x265 , xauth <ins> , xdg-utils </ins> , xorg , xorgserver }:


Question: Xpra supports forwarding invocations from the server to the client. The Xpra client defaults to hardcoding as the command to invoke on the client, which does not exist in NixOS. This bug does not impact hosts other than NixOS. Steps to reproduce the behavior: somehow. The Xpra client should invoke the local . N/A. This could be fixed by setting the open command to just , but it might match the intent better to change it to something like perhaps. Presumably, the point of doing it this way is to avoid any other copies of that might appear on the , e.g. Xpra's own. I suppose we can't really rely on to exist: even if we could on NixOS, we can't on other Linux distributions running Nix, where might make more sense. It seems to me that the best compromise, then, is to hardcode a path to copy of and users can override this using the option if needed. The open command that Xpra uses is configurable on the client-side, but the default is set as a platform-specific variable. On Linux, it is set in . Because there are separate values for both Windows and Darwin hosts, patching the value to shouldn't ever break them (but of course it should still be a Linux-specific patch, otherwise it unnecessarily brings into the closure.) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

./fix-122159.patch # https://github.com/NixOS/nixpkgs/issues/122159 ]; <ins> # Note: xposix is renamed to posix in v5. postPatch = lib.optionalString stdenv.isLinux '' substituteInPlace xpra/platform/xposix/features.py  --replace-fail "/usr/bin/xdg-open" "${xdg-utils}/bin/xdg-open" ''; </ins> INCLUDE_DIRS = "${pam}/include"; nativeBuildInputs = [


Question: The src URL () for Azure Data Studio redirects to latest version (1.48.1), not the specified version (1.44.1), leading to build failure due to hash mismatch. i.e. redirects to . Steps to reproduce the behavior: Specified version of Azure Data Studio should be downloaded, verified and installed. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

stdenv.mkDerivation rec { pname = "azuredatastudio"; <del> version = "1.44.1"; </del> <ins> version = "1.48.1"; </ins> desktopItems = [ desktopItem urlHandlerDesktopItem ]; src = fetchurl { name = "${pname}-${version}.tar.gz"; url = "https://azuredatastudio-update.azurewebsites.net/${version}/linux-x64/stable"; <del> sha256 = "sha256-6kEV331kt+/7/uWKZmTTkJX4P06CfxC8Ogq052qlUEg="; </del> <ins> sha256 = "sha256-JDNdMy0Wk6v2pMKS+NzSbsrffaEG2IneZO+K9pBFX48="; </ins> }; nativeBuildInputs = [


Question: The src URL () for Azure Data Studio redirects to latest version (1.48.1), not the specified version (1.44.1), leading to build failure due to hash mismatch. i.e. redirects to . Steps to reproduce the behavior: Specified version of Azure Data Studio should be downloaded, verified and installed. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

]; # this will most likely need to be updated when azuredatastudio's version changes <del> sqltoolsservicePath = "${targetPath}/resources/app/extensions/mssql/sqltoolsservice/Linux/4.7.1.6"; </del> <ins> sqltoolsservicePath = "${targetPath}/resources/app/extensions/mssql/sqltoolsservice/Linux/4.11.1.1"; </ins> rpath = lib.concatStringsSep ":" [ (lib.makeLibraryPath [


Question: Project description goread is an RSS/Atom feed reader for your terminal. It allows you to categorize and follow feeds and read articles right in the terminal. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:

githubId = 15379000; name = "schneefux"; }; <ins> schnow265 = { email = "thesnowbox@icloud.com"; github = "schnow265"; githubId = 57457177; name = "Luca Scalet"; }; </ins> schnusch = { github = "schnusch"; githubId = 5104601;