jiebi/CodeConvo huggingface dataset:
Change:
]; in stdenv.mkDerivation rec { pname = "insomnia"; <del> version = "2023.5.8"; </del> <ins> version = "8.6.1"; </ins> src = fetchurl { url = "https://github.com/Kong/insomnia/releases/download/core%40${version}/Insomnia.Core-${version}.deb"; <del> sha256 = "sha256-x5DYS3DteYtq1EQuJ3EFV/d/YThPgnhhIj+GpEJsFDY="; </del> <ins> hash = "sha256-qy2j6kdmtDgfTab8gTz7eb/uNKwtzbxcoJHNibVa35c="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: insomnia Latest released version: 8.6.1 <!-- Search your package here: --- Current version on the unstable channel: 2023.5.8 Current version on the stable/release channel: 2023.5.8 <!-- 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. As of right now the app crashes with the following log: Turning off in the config file () also didn't seem to fix it, so I assume that updating the package to the latest version will fix the issue (at least temporarily). Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
compactStringFix = callPackage ../development/libraries/haskell/compact-string-fix {}; <ins> concatenative = callPackage ../development/libraries/haskell/concatenative {}; </ins> conduit = callPackage ../development/libraries/haskell/conduit {}; ConfigFile = callPackage ../development/libraries/haskell/ConfigFile {};

Discussion:
Kdenlive build fails because CMake can't find QtConcurrent. Error: It appears to have been broken by some changes made to qtbase but I am not familiar enough with it to know what specifically. Changes between success and first failure: Latest Hydra failure: cc Attempt to install Kdenlive System: NixOS: 17.09pre107928. (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: "17.09pre107928." Sandboxing enabled: build-use-sandbox = true
You need to modify the to We should send a patch upstream. This must be a required change since QT5.8.
Fixed by:
Change:
perl psmisc python3 <ins> unzip </ins> which xorg.xrandr zstd

Discussion:
Heroic Launcher while trying to install a game from gog will download it, but won't install it. You can see downloaded installer inside your directory. After "installation", launcher will say on the game's details screen that It should install. ! You can't just use the gog installer like in a normal linux distribution: So you need to use steam-run to install it. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --heroic-launcher: 2.9.2 - unstable nixpkgs
This sounds exactly like a bug I encountered in a previous version of Heroic, but they have since fixed it, and I have not run into it on 2.9.2. Could you please attach the Heroic log file from right after trying to install the game? It's accessible via the sidebar Settings-Log.
<details</details
It looks like it successfully installs, going by that log. I seem to vaguely recall now having some issues with my GOG library in Heroic 2.9.2, and I eventually removed (with Heroic closed) and logged in to GOG through Heroic again, and it's been behaving since. You might try that, otherwise I don't see anything indicating this would be an issue specific to the Heroic package, so I think it would be appropriate to go to upstream's support channel, which is .
I will try moving to nixpkgs unstable and see if it was an issue of using stable and unstable in the same time. It should not, but maybe it is. Thank you for your help PS. I tried different game and the situation is still the same.
I found that heroic needs unzip to be installed to extract the gog linux installers. When I have somewhere in my installed packages (home or system), it just works. Probably it will have to be to the heroic wrapper.
Could you please try changing in your Nix config to the following and see if that fixes your problem?
By using: Everything started to work.
Change:
<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;

Discussion:
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]:
Change:
cd "$(dirname ${BASH_SOURCE[0]})"  # nixpkgs root <del> testDirectReferences() { expr="$1" </del> <ins> if [[ -z ${SAMPLE:-} ]]; then sample=( `nix-build test/sample.nix` ) directRefs=( `nix-build test/invoke-writeDirectReferencesToFile.nix` ) references=( `nix-build test/invoke-writeReferencesToFile.nix` ) else # Injected by Nix (to avoid evaluating in a derivation) # turn them into arrays sample=($SAMPLE) directRefs=($DIRECT_REFS) references=($REFERENCES) fi echo >&2 Testing direct references... for i in "${!sample[@]}"; do echo >&2 Checking '#'$i ${sample[$i]} ${directRefs[$i]} </ins> diff -U3  <del> <(sort <$(nix-build --no-out-link --expr "with import ../../.. {}; writeDirectReferencesToFile ($expr)"))  <(nix-store -q --references $(nix-build --no-out-link --expr "with import ../../.. {}; ($expr)") | sort) } </del> <ins> <(sort <${directRefs[$i]})  <(nix-store -q --references ${sample[$i]} | sort) done </ins> <del> testDirectReferences 'hello' testDirectReferences 'figlet' testDirectReferences 'writeText "hi" "hello"' testDirectReferences 'writeText "hi" "hello ${hello}"' testDirectReferences 'writeText "hi" "hello ${hello} ${figlet}"' testClosure() { expr="$1" </del> <ins> echo >&2 Testing closure... for i in "${!sample[@]}"; do echo >&2 Checking '#'$i ${sample[$i]} ${references[$i]} </ins> diff -U3  <del> <(sort <$(nix-build --no-out-link --expr "with import ../../.. {}; writeReferencesToFile ($expr)"))  <(nix-store -q --requisites $(nix-build --no-out-link --expr "with import ../../.. {}; ($expr)") | sort) } testClosure 'hello' testClosure 'figlet' testClosure 'writeText "hi" "hello"' testClosure 'writeText "hi" "hello ${hello}"' testClosure 'writeText "hi" "hello ${hello} ${figlet}"' </del> <ins> <(sort <${references[$i]})  <(nix-store -q --requisites ${sample[$i]} | sort) done </ins> echo 'OK!'

Discussion:
There is an issue in the test by . This line introduces a dependency on the contents of nixpkgs, making every change evaluate with a different hash. cc
Steps to reproduce:
You're absolutely right, but I don't think I see the impact of this fact. It's not recursed into (no /) and it's not even built by ofborg. The test needs to compare results, but perhaps the actual evaluation can be removed from it; injected as store paths by the test runner instead. It won't make the test easier to read :(
This currently impacts every ofborg evaluation. For example:
I have no idea how to solve this. Why would ofborg have a different hash for multiple evaluations? Cause it puts stuff in the nixpkgs path?
is the whole Nixpkgs source tree, which kinda always changes. Here's a solution . Not pretty but still quick to run outside the sandbox and solves this issue.
Still an issue ?
Ofborg doesn't rebase PRs so if the PR is based on a master that's of the wrong age, you'll still see this happen. Please check that the PR includes the improved test.
I did, and it's been more than 12 hours since the commit landed. At the same time my original repro doesn't see the issue:
It's a broader issue that applies to all NixOS tests, , but it went under the radar.
This seems to be fixed now. Thanks for looking into this!
Change:
gstreamer gst-plugins-base gst-plugins-good <ins> gst-plugins-bad </ins> gst-plugins-ugly ]) ++ lib.optional withVlc libvlc;

Discussion:
When I play for example an AAC, strawberry complains about missing gstreamer plugins. A window pops open with the following text: an AAC The AAC plays just fine. I pretty much just replaced by in my config, and this started happening. So this must be some sort of regression introduced in (measured against `clementine). It seems that the relevant environment variable is set, e. g. yields:
Can you try rebuilding with to to see if that fixes it? Alternatively, does it work when you switch the backend in the application to VLC (no rebuilding needed)?
Yes that works.
Do we keep the issue open? This is definitely a workaround, but it still comes in a state which does not work per default
Change:
$out/bin/tutanota-desktop  --add-flags $out/share/tutanota-desktop/resources/app.asar  --run "mkdir -p /tmp/tutanota"  <del> --prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath [ libsecret ]} </del> <ins> --prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath [ libsecret stdenv.cc.cc.lib ]} </ins> runHook postInstall '';

Discussion:
Tutanota fail to start, i'm pretty sure I started tutanota a few days ago without an error but I can not guarantee, it would be strange as the derivation did not change since then (i update every day). Looks like it complains about a missing FileChooser interface. I'll look into it in the following days. Run in terminal. Tutanota is starting without errors. Here is my output when running in the shell The process hang there, whithout closing. If it's relevant, i'm on Wayland (sway), and i'm on channel unstable.
Can confirm I'm seeing the same issue when building from nixpkgs-unstable.
Luckily it was just adding to the LDLIBRARYPATH. From there I get a working window. Posting PR soon.
Great ! Thank you for the quick response and for maintaining the tutanota derivation !!
Change:
platforms = []; source = { remotes = ["https://rubygems.org"]; <del> sha256 = "045c1820d909307abb1d232c0cf26bbd88eafa0453004124c07b15fff5d680de"; </del> <ins> sha256 = "0as95haqa943i740xs7czcaibb8lvy4gn6kr8nbldq20nly64bih"; </ins> type = "gem"; }; <del> version = "0.8.0"; </del> <ins> version = "0.9.0"; </ins> }; fusuma-plugin-sendkey = { dependencies = ["fusuma" "revdev"];

Discussion:
The fusuma program in the package of the same name crashes when trying to run it. The breaking change causing this issue was made somewhere in the last 56 days: That's when I last updated this particular host, after which everything was still working fine. Steps to reproduce the behavior: "fusuma" package to run fusuma I expected fusuma to start running and be available for use. N/A Instead of displaying the expected behavior, the program crashes: In addition, if I clone the repo, then open a and run the cloned project in that nix-shell, that runs successfully unmodified on the same host. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks especially for the celerity of the fix!
Is there supposed to be a delay between this merge and availability updating? I can clearly see this PR is merged, but when I update my system the new version isn't in there.
Yes, see
One month later, I don't see the updated package. How long can this take ?
The update is already on master, but I don't think it's been backported yet. Are you on NixOS 23.11 instead of unstable?
Yes.
Backported in , should take a few days to land.
Many thanks for the commit !
Change:
doCheck = false; meta = with lib; { <del> description = "tool to check linux kernel source dump for known CVEs"; </del> <ins> description = "Tool to check linux kernel source dump for known CVEs"; </ins> homepage = "https://github.com/evdenis/cvehound"; <ins> changelog = "https://github.com/evdenis/cvehound/blob/${src.rev}/ChangeLog"; </ins> # See https://github.com/evdenis/cvehound/issues/22 <del> license = with licenses; [ gpl2Only gpl3Only ]; </del> <ins> license = with licenses; [ gpl2Only gpl3Plus ]; </ins> maintainers = with maintainers; [ ambroisie ]; }; }

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! --- cvehound <!-- 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: 1.0.4 desired version: 1.0.9 <!-- 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:
inherit (darwin.apple_sdk.frameworks) Cocoa CoreGraphics Foundation IOKit Kernel OpenGL; }; <ins> kitty-themes  = callPackage ../misc/kitty-themes {}; </ins> lxterminal = callPackage ../applications/terminal-emulators/lxterminal { }; microcom = callPackage ../applications/terminal-emulators/microcom { };

Discussion:
kitty-themes Themes for the kitty terminal emulator Metadata homepage URL: source URL: license: gpl3 platforms: linux, darwin
Change:
<ins> { lib, fetchurl, stdenvNoCC, testers, }: stdenvNoCC.mkDerivation (finalAttrs: { pname = "vfkit"; version = "0.5.1"; src = fetchurl { url = "https://github.com/crc-org/vfkit/releases/download/v${finalAttrs.version}/vfkit"; hash = "sha256-at+KsvsKO359d4VUvcSuio2ej5hM6//U4Mj/jqXwhEc="; }; dontUnpack = true; installPhase = '' runHook preInstall install -Dm755 $src $out/bin/vfkit runHook postInstall ''; passthru.tests = { version = testers.testVersion { package = finalAttrs.finalPackage; }; }; meta = { description = "Simple command line tool to start VMs through the macOS Virtualization framework"; homepage = "https://github.com/crc-org/vfkit"; license = lib.licenses.asl20; maintainers = with lib.maintainers; [ sarcasticadmin ]; platforms = lib.platforms.darwin; # Source build will be possible after darwin SDK 12.0 bump # https://github.com/NixOS/nixpkgs/pull/229210 sourceProvenance = [ lib.sourceTypes.binaryNativeCode ]; mainProgram = "vfkit"; }; }) </ins>

Discussion:
Project description vfkit - Simple command line tool to start VMs through macOS Virtualization Framework This is (apparently) required by Podman 5.0.x and Darwin. See: Metadata homepage URL: source URL: license: Apache 2.0 platforms: darwin
I can confirm this is required by podman 5 on macOS in order to start the virtual machine uses to run containers
The reason I said "apparently" was because although I had observed that I needed to install to get Podman to work, I wasn't 100% sure there wasn't an alternative configuration.
I know the PR is closed but it's worth mentioning it didn't work.
I know the PR is closed but it's worth mentioning it didn't work. yeah, I could build it with our Darwin SDK, but it seems to disable too many features to make it usable. I think you can use the following:
Could you elaborate a bit on which features needed to be disabled and why,
: I just hit this problem and found this issue. Is there a specific reason that specific package was not yet submitted upstream, or could I (beginner) do that?
Change:
joplin = prev.joplin.override (oldAttrs:{ nativeBuildInputs = [ pkgs.pkg-config <ins> (pkgs.python3.withPackages (ps: [ ps.setuptools ])) </ins> ] ++ lib.optionals stdenv.isDarwin [ pkgs.xcbuild ];

Discussion:
Steps to reproduce the behavior: joplin I ping another package's maintainer, sorry. also I can't find maintainer of that package. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
sozu = callPackage ../servers/sozu { }; <del> sparrow = callPackage ../applications/blockchains/sparrow { openimajgrabber = callPackage ../applications/blockchains/sparrow/openimajgrabber.nix { }; </del> <ins> sparrow-unwrapped = callPackage ../applications/blockchains/sparrow { openimajgrabber = callPackage ../applications/blockchains/sparrow/openimajgrabber.nix {}; openjdk = openjdk.override { enableJavaFX = true; }; }; sparrow = callPackage ../applications/blockchains/sparrow/fhsenv.nix { buildFHSUserEnv = buildFHSUserEnvBubblewrap; </ins> }; sparsehash = callPackage ../development/libraries/sparsehash { };

Discussion:
Steps to reproduce the behavior: sparrow 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.
TLDR; This was caused by and is fixed in Upstream bundles a JDK/JRE with sparrow. Our sparrow package does not use the bundled JDK and instead replaces it with a JDK from Nixpkgs. Since the sparrow bundle contains the JDK and the sparrow code in a single JIMAGE, the sparrow package compares the files in the JIMAGE with the files provided by the JDK in Nixpkgs in order to determine which files in the JIMAGE are part of the JDK. Those files are then excluded from the sparrow derivation. When disabled JavaFX by default it changed the output of the aforementioned comparison, leaving behind some files which belong to the JDK as part of the sparrow derivation; The files which are part of JavaFX. This in turn causes the patchelf procedure to fail because the sparrow package is only expected to patch sparrow-specific dependencies, not the JDK.
Change:
<del> { lib , buildPythonPackage , fetchFromGitHub , setuptools , wheel , cython , tree-sitter0_21 , pytestCheckHook , python </del> <ins> { lib, buildPythonPackage, fetchFromGitHub, setuptools, cython, tree-sitter, pytestCheckHook, python, </ins> }: buildPythonPackage rec {

Discussion:
Steps to reproduce the behavior: Originally found building Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
That's not a build failure, but an evaluation failure. If you want to make not depend on , you need to figure out where does this dependency comes from, and try to remove it. The reason we disabled is documented in the code: Note that although the issue is fixed, we intentionally provide an expression for , so that we can build with it. See also: You can work around this issue by using instead, or try to be creative and make depend on the latest (and not ), by fixing the upstream issue . Good luck!
I'm closing this, as this is an upstream issue. Ideally it would have been possible to declaratively write with Nix why packages are disabled for certain Python implementation, and that would have improved the evaluation failure message you observed. I think I saw discussion about such a feature, but I can't find any links now unfortunately.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
git-annex-adapter = callPackage ../development/python-modules/git-annex-adapter { }; <ins> git-filter-repo = callPackage ../development/python-modules/git-filter-repo { }; </ins> gitdb = callPackage ../development/python-modules/gitdb { }; github3_py = callPackage ../development/python-modules/github3_py { };

Discussion:
Project description Git-privacy redacts author and committer dates to keep your coding hours more private. You can choose the level of redaction: only remove minutes and seconds from your dates or even hide day or month. The original dates are encrypted and stored in the commit message in case you might need them. Metadata homepage URL: source URL: license: bsd2 platforms: unix, linux, darwin, ...
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
this bot is too aggressive, 180 days is not enough
I marked this as stale due to inactivity. &rarr;
Change:
homepage = http://www.lesbonscomptes.com/recoll/; license = licenses.gpl2; platforms = platforms.unix; <del> maintainers = with maintainers; [ jcumming ]; </del> <ins> maintainers = [ maintainers.jcumming ]; </ins> }; }

Discussion:
Describe the bug texlive on master fails to build since : This commit upgraded the poppler library, and upstream they "modernized the headers", including instead of in the . texlive includes this file in a plain C program, so is not available. To Reproduce Expected behavior Should build. Additional context Gentoo had this issue too: I'm not familiar enough with gentoo to understand what the fix is doing, but it looks like they fixed it by moving to an r6 version of texlive? Metadata Maintainer information: cc
No, that's versioning of gentoo-specific tarball with patches, currently and their workaround is in texlive-core-2019- inside.
The patch was applied in . I believe poppler should be blamed instead, but it should work now at least.
Change:
in rustPlatform.buildRustPackage rec { pname = "alacritty"; <del> version = "0.5.0"; </del> <ins> # 0.5.0 is not compatible with gnome 3.38 version = "0.6.0-rc1"; </ins> src = fetchFromGitHub { owner = "alacritty"; repo = pname; rev = "v${version}"; <del> sha256 = "1948j57xhqvc5y876s929x9rhd6j0xnw5c91g1zqw2rfncn602g2"; </del> <ins> sha256 = "RuIJvB0J/BQFqemOkEUiqS1uz0gMS49Dd8UQt0nbrQ0="; </ins> }; <del> cargoSha256 = "17lyzcj07f0vyki3091vgjd0w8ki11sw5m8gb3bxdph1dl04rria"; </del> <ins> cargoSha256 = "+3iZywLvy+8C7j6g9bqij2DSLjBoE2u1GXgfV04cWRY="; </ins> nativeBuildInputs = [ cmake

Discussion:
Experienced on gnome3.38 which is currently on master. alacritty 0.5.0 isn't functional at all. 0.6.0rc-1 is. Should we update in order to make our packages set functional? Or should we wait for a real, no rc release upstream?
you should update yourself in the maintainers list - I had to go to to see who is .
Is this a wayland issue on gnome?
Yes.
Sound fine to me.
Thanks for pointing this out. As much as I want to see my first username long gone, the change was not worth it :)