jiebi/CodeConvo huggingface dataset:
Code change:
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

Related discussion:
text: 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
Code change:
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

Related discussion:
text: { lib , lua , wrapLua <del> , luarocks </del> <ins> , luarocks_bootstrap </ins> , writeTextFile # Whether the derivation provides a lua module or not.
Code change:
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

Related discussion:
text: nativeBuildInputs = [ lua  # for lua.h wrapLua <del> luarocks </del> <ins> luarocks_bootstrap </ins> ]; inherit doCheck extraConfig rockspecFilename knownRockspec externalDeps nativeCheckInputs;
Code change:
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

Related discussion:
text: 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')
Code change:
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

Related discussion:
text: }; }) {}; <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";
Code change:
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

Related discussion:
text: , vimPlugins , vimUtils , yajl <ins> , zip , unzip </ins> , zlib , zziplib }:
Code change:
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

Related discussion:
text: ]; }); <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; }
Code change:
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

Related discussion:
text: <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
Code change:
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

Related discussion:
text: 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 { });
Code change:
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]:

Related discussion:
text: 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="; };
Code change:
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]:

Related discussion:
text: <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>
Code change:
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]:

Related discussion:
text: 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 { };
Code change:
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?

Related discussion:
text: 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 = ''
Code change:
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]:

Related discussion:
text: { lib , stdenv <del> , fetchgit </del> <ins> , fetchFromRepoOrCz , gnu-efi </ins> , fetchurl <ins> , fetchpatch </ins> , libuuid , makeWrapper , mtools , nasm <ins> , nixosTests </ins> , perl , python3 }:
Code change:
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]:

Related discussion:
text: # 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
Code change:
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]:

Related discussion:
text: "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 = [
Code change:
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]:

Related discussion:
text: buildInputs = [ libuuid <ins> gnu-efi </ins> ]; # Fails very rarely with 'No rule to make target: ...'
Code change:
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]:

Related discussion:
text: "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;
Code change:
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]:

Related discussion:
text: 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 ];