jiebi/CodeConvo huggingface dataset:
Change:
linkVimlPlugin = plugin: packageName: dir: '' mkdir -p $out/pack/${packageName}/${dir} <ins> if test -e "$out/pack/${packageName}/${dir}/${lib.getName plugin}"; then printf "nERROR - Duplicated vim plugin: ${lib.getName plugin}nn" exit 1 fi </ins> ln -sf ${plugin}/${rtpPath} $out/pack/${packageName}/${dir}/${lib.getName plugin} '';

Discussion:
Not sure. Issue exists after updating unstable from to
I also got hit by this problem. This seems caused by this PR: My system builds fine with the commit just before that (), but not after () <details<summaryBuild logs</summary</details
It would be nice to reproduce it locally, to find a proper fix. are you doing anything special to install the vim plugins? Do you have your configuration somewhere online?
Sure. My config lives here: I'm configuring Neovim through the home-manager module.
thanks, I'm using home-manager too, but so far I cannot reproduce it, I'll take a look to your config
I can reproduce it, but looks like an error with you config, you are installing 2 times the same plugin, here: and here:
That was it I was able to update nixpkgs, thanks!
in your case, is the same reason? Maybe we could try to add a better error message
In my case it is And I do not see that there is anything duplicated...
I see that you are using some out of tree vim plugins (fzf-preview is not in nixpkgs). Is the nix expression with those plugins public? Maybe a copy/paste error with your plugins? Did you forget to change the name/pname attribute for one of your plugins?
fzf-preview: None of my expressions are public, because they're in a git repository with private data. But here it is: I checked that my plugins are named correctly and they are. The error: Indicates that there's something wrong with a fzf plugin, yes. But I do nothing fancy with fzf in my configuration:
I think that is caused by , fzf-vim also installs fzf in your vim plugins, you only need
you're right, that solved the issue for me! Thanks! But now it does not find - I guess this is unrelated though!
I don't think that the error you are getting is related to this
Hm,... maybe it is... it seems that fugitive cannot be found, although it is installed...
Change:
stdenv.mkDerivation rec { pname = "SDL2"; <del> version = "2.24.0"; </del> <ins> version = "2.24.2"; </ins> src = fetchurl { url = "https://www.libsdl.org/release/${pname}-${version}.tar.gz"; <del> sha256 = "sha256-keTDSxdo+S05mweOFxRIxq8Yyv2nQ5h+0gZKKJVNbZc="; </del> <ins> sha256 = "sha256-s17wqAKwnZDtOt0NysDpWCCAQgKRT1u3sP63EPGhMp8="; </ins> }; dontDisableStatic = if withStatic then 1 else 0; outputs = [ "out" "dev" ];

Discussion:
As part of , I found that no longer builds correctly. Steps to reproduce the behavior: devilutionx it started to fail on hydra, and here's the latest . I can reproduce it locally. I think that this is the important part, where was not found: I'm the maintainer, but I'm not sure how to fix it...
Hey maybe you could help?
Maybe and ?
I built on with merged and it works now, thanks ! Closing this at it should be fixed now.
Change:
<del> { lib, rustPlatform, fetchFromGitHub, testers, cbfmt }: </del> <ins> { lib, rustPlatform, fetchFromGitHub, stdenv, testers, cbfmt }: </ins> rustPlatform.buildRustPackage rec { pname = "cbfmt";

Discussion:
Steps to reproduce the behavior: Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Interestingly, if I clone the project and use then run it builds just fine
Change:
<ins> #!/usr/bin/env nix-shell #!nix-shell -I nixpkgs=../ -i bash -p wget yarn2nix yarn set -euo pipefail if [ "$#" -ne 1 ] || [[ "$1" == -* ]]; then echo "Regenerates the Yarn dependency lock files." echo "Usage: $0 <git release tag>" exit 1 fi SRC="https://raw.githubusercontent.com/atom/node-keytar/$1" wget "$SRC/package-lock.json" wget "$SRC/package.json" rm -f yarn.lock yarn import yarn2nix > yarn.nix rm -rf node_modules package.json package-lock.json </ins>

Discussion:
Describe the bug Riot-Desktop -Security & Privacy Under the "Message search" heading, observe: Riot is missing some components required for securely caching encrypted messages locally. If you'd like to experiment with this feature, build a custom Riot Desktop with search components . it links to here: Notify maintainers cc: Metadata Maintainer information:
Would be fantastic to have built with . I tried building it myself but couldn't do it. :cry:
Just stumbled across this myself. What's the current state on this? What needs to be done before this can be fixed?
So, element seems to use its own build system to build these native dependencies. It tries to download and build those itself with cargo and stuff. Seems quite complicated to package.
I would like to add that support for desktop notifications would be also appreciated. (They showed up on Arch's version, at least) Edit: This problem has been resolved since
I made some progress. This solves the issue of downloading the hakDependencies. Unfortunately they are not locked in any way, so we need to lock them at packaging-time (is that even a term?) by adding them to and Since yarn2nix always runs yarn with , we can safely ignore the upstream reasoning for fetching them outside of yarn dependencies. I'm now at the point where it tries to build seshat in the element-desktop derivation, but unfortunately they don't provide a Cargo lockfile. I'm working on resolving this problem upstream: <details</details
It turns out to be much more complicated, because the cargo build of seshat-node-native calls , so we have multiple layers of npm calling yarn calling cargo calling npm. With lots of things being downloaded and executed. It's a huge shitshow.
Is there anything we could do to help fix building with encrypted chat search working on NixOS?
I poured some (many) more hours into this today. I can build the two native modules, matrix-seshat and keytar, both in a seperate derivation and as part of the element-desktop build. However, I can not build them correctly against electron's node lib, so when starting the compiled thing, it refuses to load the module. Attempting to build against electron gives a mystic error.

Or the second approach, with everything in one derivation using the hak tool: <details</details<rantHonestly it's just a horrible build system. hak and neon and so on don't give any consideration to users who want to build the libraries in an environment without an internet connection. </rant If you can find a fix for the error, there shouldn't be much work left.
I think I found the solution to that error: Upstream is using Electron 12.x while we are using Electron 13.x.
! PR incoming :sparkles:
Change:
substituteInPlace  src/runtime/src/native/libs/CMakeLists.txt  --replace-fail 'add_compile_options(-Weverything)' 'add_compile_options(-Wall)' <ins> # strip native symbols in runtime # see: https://github.com/dotnet/source-build/issues/2543 xmlstarlet ed  --inplace  -s //Project -t elem -n PropertyGroup  -s $prev -t elem -n KeepNativeSymbols -v false  src/runtime/Directory.Build.props </ins> '' + lib.optionalString isLinux '' substituteInPlace 

Discussion:
All dotnet9 packages are failing on hydra because the output is ~4.2G. It looks like binaries aren't being stripped, so I'm going to investigate build flags, etc.
Change:
nativeBuildInputs = [ unzip makeWrapper ]; buildInputs = [ <del> (python3.withPackages (ps: [ ps.lxml ps.numpy ps.gevent ps.gevent-websocket ps.pillow ])) </del> <ins> (python3.withPackages (ps: [ ps.lxml ps.numpy ps.gevent ps.gevent-websocket ps.pillow ps.setuptools ])) </ins> ] ++ runtimeProgDeps; installPhase = ''

Discussion:
Bazarr doesn't start. Steps to reproduce the behavior: `nix run 'nixpkgs/nixos-unstable#bazarr' Bazarr starts and work
While you wait that the PR is merged you can add this overlay to fix the issue: I wanted to come up with a way to merge in the old buildInputs and only add setuptools but I wasn't able to come up with a way. If someone has an better solution I am eager to learn how to do it.
Change:
<del> { stdenv, fetchurl, mkDerivation, makeWrapper, makeDesktopItem, autoPatchelfHook , wrapQtAppsHook </del> <ins> { stdenv, fetchurl, mkDerivation, autoPatchelfHook , fetchFromGitHub </ins> # Dynamic libraries , dbus, glib, libGL, libX11, libXfixes, libuuid, libxcb, qtbase, qtdeclarative , qtimageformats, qtlocation, qtquickcontrols, qtquickcontrols2, qtscript, qtsvg

Discussion:
Describe the bug is missing its icon, because it does not appear in the source tarball. I see a couple of options to fix: the icon separately, perhaps from the source to one of the packaged releases for another distro that includes the icon cc Maintainer information:
I would install the desktop file and appdata from there as well :+1:
Change:
vtable-dumper = callPackage ../development/tools/misc/vtable-dumper { }; <ins> wails = callPackage ../development/tools/wails { }; </ins> whatsapp-for-linux = callPackage ../applications/networking/instant-messengers/whatsapp-for-linux { }; whatstyle = callPackage ../development/tools/misc/whatstyle {

Discussion:
Please see I made. It should contain all necessary information. I tried to package this myself, but I've run out of ideas on how to make this work. I'm pretty new to Nix.
I've just submitted PR to add Wails to nixpkgs if you fancy giving it a test. :smile:
Works great for me! Let's go ahead and close this ticket. Thanks for your work :pray:
Change:
stdenv.mkDerivation rec { pname = "vala-language-server"; <del> version = "0.48.4"; </del> <ins> version = "0.48.5"; </ins> src = fetchFromGitHub { <del> owner = "Prince781"; </del> <ins> owner = "vala-lang"; </ins> repo = pname; rev = version; <del> sha256 = "sha256-vCQ/j0DxG9sSEquPh9TtZ5hTADPh0d8sDIDSJdUDK4s="; </del> <ins> sha256 = "sha256-gntGnz8uqGz2EGwWWyty/N1ImaUKAPtXVZcjgp73SQM="; </ins> }; passthru = {

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: vala-language-server <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 0.48.4 desired version: 0.48.5 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
{ trivialBuild , haskellPackages }: <del> trivialBuild rec { </del> <ins> let Agda = haskellPackages.Agda.bin; in trivialBuild { </ins> pname = "agda-mode"; <del> version = haskellPackages.Agda.version; </del> <ins> version = Agda.version; </ins> dontUnpack = true; # already byte-compiled by Agda builder buildPhase = '' <del> agda=`${haskellPackages.Agda}/bin/agda-mode locate` </del> <ins> agda=`${Agda}/bin/agda-mode locate` </ins> cp `dirname $agda`/*.el* . ''; meta = { <del> inherit (haskellPackages.Agda.meta) homepage license; </del> <ins> inherit (Agda.meta) homepage license; </ins> description = "Agda2-mode for Emacs extracted from Agda package"; longDescription = '' Wrapper packages that liberates init.el from `agda-mode locate` magic.

Discussion:
With the standard library, cubical and categories, agdaWithPackages has a closure size of about 4.9 GiB (): Among the larger culprits are 600 MiB of libHSAgda-[...].a and GHC itself. Personally I'm using where I zero out the dependence on GHC and just fetch the Agda binary. I've been using this for years and never encountered any problems. Should we incorporate something like this in nixpkgs?
I currently have a number of parallel installations of Agda on my machines, and I'd like to see a reduction of closure size. I think there are two separate space hogs: Haskell library. The mentions two helpers to reduce closure size: (removes references to libraries and docs) and (installs binaries in a separate output). I tried setting , but it breaks .<supSee below</supattribute passed to : I don't use Agda's GHC backend, so I provide a "fake GHC" to reduce closure size: Maybe could be changed so that disables compilation via GCH. E.g. we could pass and to the wrapped binary. I applied to the Haskell package . Running results in the following output: Result of run on x86_64-linux <details<summary2 packages marked as broken and skipped:</summary<ul<licedille</li<liemacsPackages.cedille</li</ul</details<details<summary1 package failed to build:</summary<ul<liemacsPackages.agda2-mode</li</ul</details<details<summaryBuild log of <codeemacsPackages.agda2-mode</code</summary</details
Change:
xorg.libXi xorg.libXrender xorg.libXtst <ins> xorg.libXxf86vm </ins> zlib <del> ]; </del> <ins> ] ++ lib.optionals (stdenv.isLinux && enableJavaFX) runtimeDependencies; autoPatchelfIgnoreMissingDeps = if (stdenv.isLinux && enableJavaFX) then [ "libavcodec*.so.*" "libavformat*.so.*" ] else null; </ins> installPhase = '' mkdir -p $out

Discussion:
Attempt to build with JavaFX: . The build fails due to being unable to satisfy dependencies. The issue seems to occur for other versions of as well. Build was attempted in a flake with Nixpkgs pinned to , <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I remember encountering this during a last bump, but eventually abandoned it because something like point to obsolete versions of ffmpeg that no longer exist in Nixpkgs. I'll probably mark with on Linux as broken at some time this week.
Oh, there's actually for that. Would you please test if works?
Change:
) # List common include file locations not under the common prefixes. <del> +if(IS_DIRECTORY $ENV{NIX_CC} +  AND EXISTS $ENV{NIX_CC}/nix-support/orig-libc +  AND EXISTS $ENV{NIX_CC}/nix-support/orig-libc-dev) </del> <ins> +if(DEFINED ENV{NIX_CC} +  AND IS_DIRECTORY "$ENV{NIX_CC}" +  AND EXISTS "$ENV{NIX_CC}/nix-support/orig-libc" +  AND EXISTS "$ENV{NIX_CC}/nix-support/orig-libc-dev") </ins> +  file(STRINGS "$ENV{NIX_CC}/nix-support/orig-libc" _nix_cmake_libc) +  file(STRINGS "$ENV{NIX_CC}/nix-support/orig-libc-dev" _nix_cmake_libc_dev) +else()

Discussion:
In this commit: , the code checks the env var without quotes, which means an unset or empty variables can cause build errors, eg this one for the Rust crate in a nix shell: I'm not sure it's missing quotes though, I don't know how CMake works in this situation, but since that looks like a bash-inspired syntax, I suppose it has bash-inspired bugs too Full error: Temporary workaround: Set to garbage, like , and it will build and run correctly
Ping the relevant people and link this issue in the original PR
probably it is duplicate of
Change:
patches = [ ./7.79.1-darwin-no-systemconfiguration.patch <ins> ./7.82.0-openssl-fix-CN-check.patch </ins> ]; outputs = [ "bin" "dev" "out" "man" "devdoc" ];

Discussion:
A clear and concise description of what the bug is. Failed to run , caused by the failure of building . Run confirms this proflem Steps to reproduce the behavior: A clear and concise description of what you expected to happen. should succeed. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
FYI: succeeds on .
builds fine (using nix-shell) on unstable fails with: It seems it has something to do with the recent update of openssl:
After bisecting the error, I get this commit to be responsible: my bisecting commands:
I did a git bisect. This is the result: <details</detailsThe obvious change here is the update of curl 7.81.0 -7.82.0.
Oh, we did the same. I investigated more and found and This seems to be the fix:
I'm kinda new to nix and I would be happy making a PR with the patch :) If you haven't already started
No not yet. https://patch- is probably the patch file (generated from ) you are looking for. Adding this to should fix the issue. I don't have time right now, so if you want to create the PR, I'd be happy :smile:
I'm curious, what kind of bisect did you do? because you didn't get the same commit
I ran which should give me the complete merge commits (like staging) and works faster when doing rebuilds. Then I read what changed in that merge and look for possible candidates. I look at for the history of and look for the first good commit and bisect between those.
Oh thanks a lot! I was wondering if there was a way to get this history of commits, because yeah, it took a while to compile all those commits without hydra cache ;) and yeah makes a lot of sense too
yeah, that was my issue, too. Thanks for posting your command, I think next time I'll use the command as well. (Did the bisect manually)
I think this is fixed by (well it just disables the tests, but it works).

Its stuck in staging though
yeah. We shouldn't disable these tests. They detected a regression in curl and this is why we have them, isn't it?
I agree, I'm going ahead with the PR with the proper patch.
Change:
buildPythonPackage rec { pname = "nbxmpp"; <del> version = "2.0.3"; </del> <ins> version = "2.0.4"; </ins> disabled = pythonOlder "3.7";

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: gajim <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.3.2 desired version: 1.3.3 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
loginCfgFile = optional cfg.ssh.enable { source = pkgs.writeText "login_duo.conf" configFile; mode   = "0600"; <del> uid    = config.ids.uids.sshd; </del> <ins> user   = "sshd"; </ins> target = "duo/login_duo.conf"; }; pamCfgFile = optional cfg.pam.enable { source = pkgs.writeText "pam_duo.conf" configFile; mode   = "0600"; <del> uid    = config.ids.uids.sshd; </del> <ins> user   = "sshd"; </ins> target = "duo/pam_duo.conf"; }; in

Discussion:
was removed last Should we bring this uid back?
/cc looks-like-maintainer
What's the status of this for 16.03?
also present in 16.03 heres my relevant to reproduce:
Prepared PR to reverse the uid deletion
I noticed you have updated duosec to the latest upstream . May I know how you are enabling it? The service is still broken as I mentioned in cc
I haven't been using duosec, and am not on nixOS. I just updated it in response to your issue that said it was outdated. This issue had nothing that suggested duosec itself had a breaking change, so I went ahead with it.
Change:
src = fetchFromGitHub { owner = "intel"; repo = "gmmlib"; <del> rev = "${pname}-${version}"; </del> <ins> rev = "intel-gmmlib-${version}"; </ins> sha256 = "0dzqfgbd0fxl8rxgf5nmj1jd4izzaqfb0s53l96qwz1j57q5ybj5"; };

Discussion:
The build of fails on i686. Fails with: Found with Please run and paste the result. Maintainer information:
if you don't ping any maintainer likely nothing will happen ping
I think I never tried compiling intel-media-driver on i686 but only fixed an eval error in nixGL. The problem seems to be that it compiles 64 bit code on 32 bit.
I did a quick look what other distros do and found this helpful Debian patch () at least fixes. There are still some other compile errors that need fixing. Edit1: and with it compiles
Change:
# unaccelerated routines. cmakeFlags = [ "-DTILEDB_WERROR=0" <del> ]; </del> <ins> ] ++ lib.optional (!useAVX2) "-DCOMPILER_SUPPORTS_AVX2=FALSE"; </ins> nativeBuildInputs = [ clang-tools

Discussion:
The latest libtiledb package for x86_64-linux results in an 'Illegal instruction (core dumped)' Steps to reproduce the behavior: journalctl for systemd-coredump logs: No crash. <!-- 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.
As additional info, this issue does not happen on all machines. We encountered this mainly on VMs. One deployment was in a VMWare cluster and the other in an OpenStack environment of a public cloud. Furthermore, we did not have this issue with NixOS 22.11. We hit this issue while trying to upgrade to 23.05.
It seems that the version of tiledb that is provided in the nixpkgs cache was build with AVX instructions. The version from nixos 22.11: The version from nixos 23.05:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Running gdb on gdalinfo gives:
Yeah, it's a global constructor for from . Adding clearly shows that gets to every source file in , not just one. Probably caused by looks off.
Looks like you should be able to it to force not passing .
I can confirm that adding to in the derivation does the trick. However, this then removes all AVX code from the library. So any will then also no longer work. Unless anyone has any better ideas, I would propose to introduce a option to the derivation and then use:
Change:
"--enable-dom" ]; # Add a PHP lower version bound constraint to avoid applying the patch on older PHP versions. <del> patches = lib.optionals ((lib.versions.majorMinor php.version == "8.2" && lib.versionOlder php.version "8.2.14" && lib.versionAtLeast php.version "8.2.7") || (lib.versions.majorMinor php.version == "8.1" && lib.versionAtLeast php.version "8.1.27")) [ </del> <ins> patches = lib.optionals ((lib.versions.majorMinor php.version == "8.2" && lib.versionOlder php.version "8.2.14" && lib.versionAtLeast php.version "8.2.7") || (lib.versions.majorMinor php.version == "8.1")) [ </ins> # Fix tests with libxml 2.12 # Part of 8.3.1RC1+, 8.2.14RC1+ (fetchpatch {

Discussion:
Steps to reproduce the behavior: php-simplexml-8.1.2 This happen after latest flake update Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hydra build : and seem fine: Probably related: (fixes for 8.2 and 8.3 with same error) 1 is out of active support, so there was no backport for from upstream PS you did not ping any maintainers for that package, so they would need to notice this issue (which is unlikely)
Also causes an lsp-plugins build failure. Gonna ping maintainers.
this is fixed in master
forgive my ignorance, but what needs to happen for the fix on master to make its way to the unstable channel? I would love to be able to rebuild my system soon
fixed "lsp-plugins build failure" (it does not depend on php 8.1 version now) If your system update depends on in some other way it won't help. does not build on current master as of (2024-07-30T19:50:23Z)
Well if you only need to rebuild your system again and you don't necessarily care about the updates you're missing out on, you can try using a previous version of your file