jiebi/CodeConvo huggingface dataset:
Change:
libportal-gtk4 ]; <ins> postPatch = '' # gjs uses the invocation name to add gresource files # - https://gitlab.gnome.org/GNOME/gjs/-/blob/6aca7b50785fa1638f144b17060870d721e3f65a/modules/script/package.js#L159 # - https://gitlab.gnome.org/GNOME/gjs/-/blob/6aca7b50785fa1638f144b17060870d721e3f65a/modules/script/package.js#L37 # To work around this, we manually set the the name as done in foliate # - https://github.com/NixOS/nixpkgs/blob/3bacde6273b09a21a8ccfba15586fb165078fb62/pkgs/applications/office/foliate/default.nix#L23 sed -i "1 a imports.package._findEffectiveEntryPointName = () => 're.sonny.Junction';" src/bin.js # /usr/bin/env is not accessible in build environment substituteInPlace troll/gjspack/bin/gjspack --replace "/usr/bin/env -S gjs" "${gjs}/bin/gjs" ''; </ins> postInstall = '' <del> # autoPatchShebangs does not like "/usr/bin/env -S gjs" substituteInPlace $out/bin/re.sonny.Junction --replace "/usr/bin/env -S gjs" "/usr/bin/gjs" </del> <ins> # autoPatchShebangs does not like "/usr/bin/env -S <environment-setting> gjs -m" sed -i "1s|.*|#!/usr/bin/gjs -m|" $out/bin/re.sonny.Junction </ins> ''; meta = with lib; { <ins> mainProgram = "re.sonny.Junction"; </ins> description = "Choose the application to open files and links"; homepage = "https://apps.gnome.org/en/app/re.sonny.Junction/"; license = licenses.gpl3Plus;

Discussion:
running from displays a transparent window which is only drawn after 40 seconds (I timed it, it's not an exaggeration). Similarly, clicking the menu button takes about 20s to display the menu. Only the close button is "fast". Steps to reproduce the behavior: 's slow ... it displays fast on the right is the transparent window and my wallpaper. ! I'm not running gnome, but xfce+i3+picom if it's relevant. But as junction eventually works, something is probably not missing. cc system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): nixpkgs:
Opens within a few seconds here with LXQt on a twelve-year old CPU... tested with:
I'm using plasma on unstable and I experience normal app delay. (1-2 seconds). (Maybe one or two iterations old). There is ; however, I do not know how applicable it is. I tried to follow the steps using a shell based on the derivation (plus blueprint-compiler) but I encounter the following error (will try again tomorrow) PS: Also thanks, I didnt realize that I needed to update junction to 1.6 (I'll try to do it soon, .... but its a javascript dependency)
Note: the issue does not happen with the flatpak.
it's actually caused by setting to 1, a workaround to
Change:
# A wrapper around sage that makes sure sage finds its docs (if they were build). callPackage ./sage.nix { inherit sage-tests sage-with-env sagedoc jupyter-kernel-definition; <del> inherit withDoc; </del> <ins> inherit withDoc requireSageTests; </ins> }

Discussion:
Is it possible to load additional python libraries when using sage. For example, if I want to load , how do I do so? <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Possible solution
Change:
stdenv.mkDerivation rec { pname = "libmysofa"; <del> version = "1.1"; </del> <ins> version = "1.2"; </ins> src = fetchFromGitHub { owner = "hoene"; repo = "libmysofa"; rev = "v${version}"; <del> sha256 = "12jzap5fh0a1fmfy4z8z4kjjlwi0qzdb9z59ijdlyqdzwxnzkccx"; </del> <ins> sha256 = "sha256-f+1CIVSxyScyNF92cPIiZwfnnCVrWfCZlbrIXtduIdY="; </ins> }; nativeBuildInputs = [ cmake ];

Discussion:
, CVSSv3=8.8 (nixos-20.09, nixos-unstable) CVSSv3=6.5 (nixos-20.09, nixos-unstable) CVSSv3=6.5 (nixos-20.09, nixos-unstable) CVSSv3=6.5 (nixos-20.09, nixos-unstable) CVSSv3=6.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
This is my first contribution "the Vulnerability roundup effort". I couldn't find any documentation / tutorial on how to get started (I searched on the wiki, the contributor guide, and the Discourse...). Is there any? As I found a commit that updates , I suspect that is patched now. How can I verify it?
Welcom! Yes, I have to admit that the whole process is currently under-documented. We're on it. Basically, the usual contribution mechanisms apply. In a nutshell: Vulnerable packages on unstable should be updated if there is a new upstream release available. For the current stable release it depends. Minor updates are ok, but we must be careful not to break compatibility. So it is often helpful to see what other distros are doing and if/what patches are available. In this specific case everything looks fine so we can close the issue. Check on if your updates have landed in the appropriate branches:
Change:
<del> { lib, stdenv, fetchurl, pkg-config, glib, which, bison, nixosTests, linuxHeaders }: </del> <ins> { lib, stdenv, fetchurl, pkg-config, glib, which, bison, nixosTests, linuxHeaders, gnutls }: </ins> stdenv.mkDerivation rec { pname = "nbd";

Discussion:
Thank you for packaging NBD! However, the current NBD package does not have TLS support. Is it possible to add TLS support to the compile process? Set and try to connect to an TLS-enabled server. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Change:
]; meta = { <ins> homepage = "https://github.com/altlinux/libutempter"; </ins> description = "Interface for terminal emulators such as screen and xterm to record user sessions to utmp and wtmp files"; longDescription = '' The bundled utempter binary must be able to run as a user belonging to group utmp.

Discussion:
A follow up to It seems like is not getting updated when tmux sessions begin/end. Relevant links: Steps to reproduce the behavior: and note the results. a different shell, open a new tmux session: exiting tmux, run again and note that the results are the same. Tmux user sessions to show up in , , and , as is custom in other OSes. n/a n/a <!-- 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.
Change:
<del> { config, lib, pkgs, ...}: </del> <ins> { config, lib, pkgs, ... }: </ins> let cfg = config.programs.wayfire; in

Discussion:
A clear and concise description of what the bug is. Steps to reproduce the behavior: wayfire with wayfire from the terminal (it doesn't need a display manager, and I couldn't get one to work but that's irrelevant here) Wayfire launches It gives the following error However, if I also enable sway: Then wayfire launches as intended. Clearly sway installs some dependencies (e.g. wlroots or something) that are required by wayfire that the package does not. It would be cleaner to allow only installing wayfire and not have to also install sway. <!-- 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]:
This seems not to be a bug in the wayfire package, but with the nixos wayfire module. It seems is the relevant maintainer for programs.wayfire. wayfire does not import wayland-, that sets up required services like graphics and xdg, but sway does. See for a quick fix
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
buildPythonPackage rec { pname = "stem"; <del> version = "1.8.2"; </del> <ins> version = "1.8.3-unstable-2024-02-11"; </ins> disabled = pythonOlder "3.6";

Discussion:
Steps to reproduce the behavior: python3.11-stem While updating to current nixos-unstable, qutebrowser didn't build as this seems to be a dependency. <!-- 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]:
see
The patch has been merged upstream and we are waiting for a bugfix release. On the other hand, it seems to me that: stem is , and qutebrowser only depends on stem through a userscript: If stem breaks again we can simply remove it along with that userscript.
Change:
;; switch|boot|test|build|edit|repl|dry-build|dry-run|dry-activate|build-vm|build-vm-with-bootloader|list-generations) if [ "$i" = dry-run ]; then i=dry-build; fi <ins> if [ "$i" = list-generations ]; then buildNix= fast=1 fi </ins> # exactly one action mandatory, bail out if multiple are given if [ -n "$action" ]; then showSyntax; fi action="$i"

Discussion:
Run it. No error. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Workaround is to symlink your flake to /etc/nixos or to supply flake flag with path to your flake.
Supplying the flake with a flag works for me. Did not try the symlink.
Could you please be more specific? I don't understand what you mean.
Are you using flakes for your configuration?
Yes. I think I got it, the command to run is:
Just to be clear, how would you normally use here? I might have jumped the gun in changing the name of the issue, and maybe it's more like "nixos-rebuild: better error messages when missing and flakes both"
The point is that you don't need to search / know where the config is located if you're just listing generations
I always have to use the argument. And yes I agree with this. The current title, "nixos-rebuild: Don't search for config when using list-generations" is better IMO.
As a workaround until the PR lands, you can run to suppress the error.
Thank you, this served well to confirm my assumptions. And yes, exactly what I had in mind as the root cause.
Change:
<ins> { lib , stdenv , buildDotnetModule , fetchFromGitHub , dotnetCorePackages , mono }: buildDotnetModule rec { pname = "bicep"; version = "0.26.54"; src = fetchFromGitHub { owner = "Azure"; repo = "bicep"; rev = "v${version}"; hash = "sha256-Obu9I2FzuYBD466DE9VZnjTHSRX+qeKqTiIJ2433DQc="; }; projectFile = "src/Bicep.Cli/Bicep.Cli.csproj"; nugetDeps = ./deps.nix; dotnet-sdk = dotnetCorePackages.sdk_8_0; dotnet-runtime = dotnetCorePackages.runtime_8_0; doCheck = !(stdenv.isDarwin && stdenv.isAarch64); # mono is not available on aarch64-darwin nativeCheckInputs = [ mono ]; testProjectFile = "src/Bicep.Cli.UnitTests/Bicep.Cli.UnitTests.csproj"; passthru.updateScript = ./updater.sh; meta = { broken = stdenv.isDarwin; description = "Domain Specific Language (DSL) for deploying Azure resources declaratively"; homepage = "https://github.com/Azure/bicep/"; changelog = "https://github.com/Azure/bicep/releases/tag/v${version}"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ khaneliman ]; }; } </ins>

Discussion:
Project description Bicep is a declarative language for describing and deploying Azure resources It can also be used as an extension of tool. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
tests.gonic = nixosTests.gonic; }; <ins> # tests require it __darwinAllowLocalNetworking = true; </ins> meta = { homepage = "https://github.com/sentriz/gonic"; description = "Music streaming server / subsonic server API implementation";

Discussion:
Steps to reproduce the behavior: latest It was reported originally in , it seems to be an issue with the version of Swift that's being used. <!-- 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]:
Change:
{ callPackage, ... } @ args: callPackage ./generic.nix (args // { <del> version = "3.0.23"; sha256 = "0cbia20bggq85q2p6gsybw045qdfqxd5xv8ihppq1hwl21sb2klz"; </del> <ins> version = "3.0.24"; sha256 = "1yxw4jg9n49dbi1mjdfpxczsznl9m6sxlzkmzjancmjzvj5s6bvz"; </ins> generation = "3_0"; })

Discussion:
, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc

, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc

, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc

, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also , ,
Change:
soundtouch srtp fluidsynth <del> libva </del> libvdpau libwebp xvidcore

Discussion:
Describe the bug Building gst-plugins-bad-1.18.0 errors out on Darwin with: To Reproduce On master: Expected behavior should compile Additional context Version bump from 1.16.2 -1.18.0 in includes new dependencies libmicrodns and libva that might be incompatible for macOS Notify maintainers Metadata
has tags on the right so chances are that isn't true and that it works on Darwin. Could you try in there?
leads to continuing down this rabbit hole leads to libpciaccess is pulled in by libdrm, which is pulled in by libva, which is pulled in by gst-plugins-bad as mentioned above. Since the cited attribute is in I don't suppose it is feasible for Darwin.
Thanks, I hadn't found that override, that's what I needed to know. This might fix it, give it a try: PR
build continues as expected, yet leads to
gist of meson-
Probably needs in on Darwin, looking at:
so disabling v4l2codecs solved the problem. Complete diff:
just noticed your comment. Yes, indeed, that was the last piece. Thx.
Change:
zstd ] ++ lib.optionals stdenv.isDarwin [ darwin.apple_sdk.frameworks.Security ]; <del> propagatedBuildInputs = [ </del> <ins> dependencies = [ </ins> bcrypt build chroma-hnswlib

Discussion:
Steps to reproduce the behavior: the chromadb python package for python310. [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): chromadb/test/auth/testbasicauth[1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): chromadb/test/aut[1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] [1/7/9 built] building python3.10-chromadb-0.5.0 (pytestCheckPhase): ... [ 4%] This is not the complete log but it is all that is visible in my terminal since only keeps the latest however many lines. The build reaches this test at 4% every time and then stalls there. I was able to fix the issue by adding an overlay to disable pytestCheckPhase, but this is obviously a workaround. <!-- 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]:
The are flaky. I will ship an update later.
Change:
license = licenses.bsd3; maintainers = with maintainers; [ manveru ]; platforms = [ "x86_64-linux" "i686-linux" "x86_64-darwin" ]; <del> broken = lib.versionOlder crystal.version "0.33"; </del> <ins> broken = lib.versionOlder crystal.version "1.0"; </ins> }; }

Discussion:
current version: 0.11.0 desired version: 0.12.0 Would you be able to share the workflow/commands/tools that you go through to upgrade mint? I know it might be a lot to ask but it would be much appreciated. I'd be happy to help with also keeping this package up to date.
Fork nixpkgs and clone it Checkout a new branch Take the latest ver and replace the version in Replace the sha256 with 52 zeroes ( easy to do in vim 52i0<esc) in nixpkgs then copy the sha256 it gives you and replace the zeroes with it cd to the mint dir, run , move the .nix file you get in to the same dir as the mint again, if it works then create a commit and a pr If you need to edit the commit https://git-
Sorry to leave you hanging steps should do the trick.
No worries! I was able to get up to running the nix-shell that suggested but I get the following error: I then tried installing crystal2nix 0.1.1 from and I get the following error: Any suggestions of what I should try next?
did you run crystal2nix in the mint repo?
also, you need to bump the crystal version to
you test it and make a pr
I tried both your suggestions but now I get the following error: This is what my generated looks like: This is what my looks like: This is what my looks like: Anything else I might be doing wrong?
sorry for not responding. you changed format to when its supposed to be just shards
thanks! I'll keep that in mind for the next time around. Thanks for updating mint :)
Change:
<ins> { rustPlatform, lib, fetchFromGitHub, pkg-config, openssl, stdenv, darwin, }: rustPlatform.buildRustPackage rec { pname = "kty"; version = "0.3.1"; src = fetchFromGitHub { owner = "grampelberg"; repo = "kty"; rev = "refs/tags/v${version}"; hash = "sha256-E9PqWDBKYJFYOUNyjiK+AM2WULMiwupFWTOQlBH+6d4="; }; nativeBuildInputs = [ pkg-config ]; env = { OPENSSL_NO_VENDOR = 1; }; buildInputs = [ openssl ] ++ lib.optionals stdenv.isDarwin ( with darwin.apple_sdk; [ frameworks.SystemConfiguration ] ); cargoHash = "sha256-mhXi4YgYT2NfIjtESjvSP5TMOl3UH3CJFwKlJriZ0/4="; meta = { homepage = "https://kty.dev/"; changelog = "https://github.com/grampelberg/kty/releases/tag/v${version}"; description = "Terminal for Kubernetes"; maintainers = with lib.maintainers; [ bot-wxt1221 ]; platforms = lib.platforms.unix; mainProgram = "kty"; }; } </ins>

Discussion:
Project description The terminal for Kubernetes. kty is the easiest way to access resources such as pods on your cluster - all without kubectl. Once kty is installed on your cluster, ssh gives you a dashboard to interact with the cluster. Metadata homepage URL: source URL: license: apache-2.0 platforms: linux, darwin
Change:
''; executable = writeScript "pantheon" '' <del> export XDG_CONFIG_DIRS=${elementary-settings-daemon}/etc/xdg:${elementary-default-settings}/etc:$XDG_CONFIG_DIRS </del> <ins> # gnome-session can find RequiredComponents for `pantheon` session (notably pantheon's patched g-s-d autostarts) export XDG_CONFIG_DIRS=@out@/etc/xdg:$XDG_CONFIG_DIRS # Make sure we use our gtk-3.0/settings.ini export XDG_CONFIG_DIRS=${elementary-default-settings}/etc:$XDG_CONFIG_DIRS # * gnome-session can find the `pantheon' session # * use pantheon-mimeapps.list </ins> export XDG_DATA_DIRS=@out@/share:$XDG_DATA_DIRS <del> exec ${gnome-session}/bin/gnome-session --session=pantheon "$@" </del> <ins> # Start pantheon session. Keep in sync with upstream exec ${gnome-session}/bin/gnome-session --builtin --session=pantheon "$@" ''; # Absolute path patched version of the upstream xsession xsession = writeText "pantheon.desktop" '' [Desktop Entry] Name=Pantheon Comment=This session provides elementary experience Exec=@out@/libexec/pantheon TryExec=${wingpanel}/bin/wingpanel Icon= DesktopNames=Pantheon Type=Application </ins> ''; in stdenv.mkDerivation rec { pname = "elementary-session-settings-unstable"; <del> version = "2020-06-11"; </del> <ins> version = "2020-07-06"; </ins> repoName = "session-settings"; src = fetchFromGitHub { owner = "elementary"; repo = repoName; <del> rev = "130c9ae221913032ed18bcf6d21e3dcdba3c4209"; sha256 = "0bzg9vbq0ssnxgcb2vxpx6x9zv8ngkm9r3ki5q83m9al9919n0pr"; </del> <ins> rev = "fa15cbd83fba0ba30e9a302db880350bff5ace52"; hash = "sha256-26H791c7OAjFYtjVChIatICSocMt0uTej1TKBOvw+6w="; </ins> }; nativeBuildInputs = [

Discussion:
Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Change:
{ stdenv, fetchurl, pkgconfig, libxml2, ncurses, libsigcxx, libpar2 <del> , gnutls, libgcrypt, zlib }: </del> <ins> , gnutls, libgcrypt, zlib, openssl }: </ins> stdenv.mkDerivation rec { name = "nzbget-${version}"; <del> version = "16.4"; </del> <ins> version = "17.0-r1686"; filename = "nzbget-17.0-testing-r1686"; </ins> src = fetchurl { <del> url = "http://github.com/nzbget/nzbget/releases/download/v${version}/${name}-src.tar.gz"; sha256 = "03sdzxxsjpxp82jpk593xls96yk29989z05j73jah21dbpkkx7lf"; </del> <ins> url = "http://github.com/nzbget/nzbget/releases/download/v${version}/${filename}-src.tar.gz"; sha256 = "0hk0hiccdk3bivdnc2635kqqdwgwf73wvis1wl9k0snds25dwfiw"; </ins> }; buildInputs = [ pkgconfig libxml2 ncurses libsigcxx libpar2 gnutls <del> libgcrypt zlib ]; </del> <ins> libgcrypt zlib openssl ]; </ins> enableParallelBuilding = true;

Discussion:
nzbget can not load shared library Use unstable channel Output: System: 16.09 Flounder Nix version: nix-env (Nix) 1.11.2
Have you tried to add zlib twice? when you use ldd, you will see that there is zlib twice.
Most certainly fixed upstream with - but not included in current stable.. 17.0 is still testing :clap:
Change:
}; meta = with lib; { <del> # Broken since 3.2.0 update, cannot handle system gmic and cimg. broken = true; </del> description = variants.${variant}.description; homepage = "http://gmic.eu/"; license = licenses.gpl3Plus;

Discussion:
We broke gmic-qt during the bump. After contacting upstream, it seems like the cmake build is not maintained anymore: They migrated to . We should align with them and rewrite a qmake derivation for gmic-qt. Edit: jtojnar advise not to migrate to qmake but instead fix the cmake issue.
Any idea what I can do so I can build my system while this is a WIP?
Install the build from an older version of nixpkgs where the package you want still builds properly. The version in branch should be building properly. For Flakes: For Non-Flake:
Thank you so much!! That section of the wiki described exactly what I was trying to do!
I just posted an upstream PR to fix this:
I've opened with a proper fix if anyone here would like to do some testing (it works for me now)

Steps to reproduce the behavior: Full log: Package built successfully in . Package failed in . I assume package failed to built somewhere in between these two pull request. Please run and paste the result.
Possibly needs update like
tried but had a compilation issue: Error:
Change:
python3.pkgs.buildPythonApplication rec { pname = "pokete"; <del> version = "0.9.0"; </del> <ins> version = "0.9.1"; </ins> format = "other";

Discussion:
Package name: pokete Latest released version: 0.9.1 Current version on the unstable channel: 0.9.0 Current version on the stable/release channel: 0.9.0 <!-- 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.