jiebi/CodeConvo huggingface dataset:
Change:
{ stdenv, lib, fetchurl, undmg }: let <del> versionComponents = [ "3" "6" "2" "548020600" ]; </del> <ins> versionComponents = [ "4" "0" "1" ]; </ins> appName = "MuseScore ${builtins.head versionComponents}"; <ins> ref = "230121751"; </ins> in stdenv.mkDerivation rec {

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: musescore <!-- 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: 3.6.2 desired version: 4.0 <!-- 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:
export CC="${targetCC}/bin/${targetCC.targetPrefix}cc" export CXX="${targetCC}/bin/${targetCC.targetPrefix}cxx" # Use gold to work around https://sourceware.org/bugzilla/show_bug.cgi?id=16177 <del> export LD="${targetCC.bintools}/bin/${targetCC.bintools.targetPrefix}ld.gold" </del> <ins> export LD="${targetCC.bintools}/bin/${targetCC.bintools.targetPrefix}ld${stdenv.lib.optionalString targetPlatform.isLinux ".gold"}" </ins> export AS="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}as" export AR="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}ar" export NM="${targetCC.bintools.bintools}/bin/${targetCC.bintools.targetPrefix}nm"

Discussion:
Describe the bug I’m trying to build the ghc package (currently at version 8.6.5) on Darwin but building fails with the error (warning: almost 2 MB) To Reproduce (this is the exact revision I’m using; it’s the Nixpkgs as of this writing) Metadata system: host os: multi-user?: sandbox: version: channels(besham): nixpkgs: Maintainer information:
This is most likely from
Change:
runHook preBuild yarn --offline electron-builder  <del> --dir --linux ${if stdenv.hostPlatform.isAarch64 then "--arm64" else "--x64"}  </del> <ins> --dir ${if stdenv.isDarwin then "--macos" else "--linux"} ${if stdenv.hostPlatform.isAarch64 then "--arm64" else "--x64"}  </ins> -c.electronDist=${electron}/lib/electron  -c.electronVersion=${electron.version}

Discussion:
Audio notifications in do not play and a pop-up appears with a JavaScript error. The error raised is quoted below: A screenshot of the error is also provided which references the store path pointing to . Steps to reproduce the behavior: . a notification from either a direct message, or the start of a meeting. with error appears. Notifications play an audio tone and do not create a Javascript error. If applicable, add screenshots to help explain your problem. ! NixOS configuration using flakes. version is 1.0.45. Other notifications in my system work fine such as Slack and Firefox. Running Hyprland, Gnome is also installed. Issue is not dependent on desktop environment as it occurs in both Gnome and Hyprland. Using for audio. Config below: <!-- 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.
Hmm, I'm surprised I haven't had this issue (and I also use sway/pipewire). I'll look into it some time in the next few days if no one else figures it out first I also planned to update the package to 1.0.49 which may fix it, but that update is waiting on because of changes to the that need newer parsing for lockfile fixup
it seems like this might be fixed by . Do you think you could give that PR a try?
I still get it using the PR.
Can you try it again? I think I found the issue and just made another push to that PR
What's the best way to test PRs? Sorry, still fairly new to NixOS. I've tried building from a tarball with but I'm getting an error as follows: I also tried the method of using a tarball in my as per but I got a different error about .
The easiest method to test is probably when the teams-for-linux client isn't already running. That builds and runs the package from that PR
I'm no longer getting the error.
Also no longer getting the error. Thanks
Change:
enableParallelBuilding = true; <del> nativeBuildInputs = [ pkgconfig ]; </del> <ins> nativeBuildInputs = [ pkgconfig ]; </ins> buildInputs = [ flex bison ] ++ lib.optional stdenv.isLinux systemd; <ins> CXXFLAGS = lib.optional stdenv.cc.isClang "-std=c++11"; </ins> flags = { # much left to do here...

Discussion:
Arcanist fails to build because one of its dependencies, seems to be , fails to build on macOS High Sierra. I've included the full output . A relevant excerpt, Run System: macOS High Sierra 10.13.1 Beta (17B46a) Nix version: 1.11.15 Nixpkgs version: 18.03pre118668. Sandboxing enabled: build-use-sandbox = false
Following the , it seems that adding an overlay to solves the issue, I can confirm this made the package work. Being quite new to nix, I don't know if this is something that should be fixed in the package itself?
Since you got this working, can you create a PR adding that CXXFLAGS attr to the derivation as optional for darwin only?
sure! Phewie, would I be correct that it's a simply matter of adding somewhere inside
In this case is probably more correct, but yes that looks good.
Change:
homepage = "https://github.com/WebAssembly/binaryen"; description = "Compiler infrastructure and toolchain library for WebAssembly, in C++"; platforms = platforms.all; <del> maintainers = with maintainers; [ asppsa ]; </del> <ins> maintainers = with maintainers; [ asppsa willcohen ]; </ins> license = licenses.asl20; };

Discussion:
Package name: emscripten Latest released version: 3.1.57 <!-- Search your package here: --- Current version on the unstable channel: 3.1.51 Current version on the stable/release channel: 3.1.47 <!-- 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]:
tl;dr: 3.1.57 is not currently compatible with the version of llvm in tree (18.1.5). The latest compatible version with llvm 18.1.5 appears to be Emscripten 3.1.54. The emscripten nixpkg (3.1.51) currently uses an LLVM17 environment which needs be migrated to LLVM18. The configuration as it exists today doesn't work in some cases. (Godot4.3dev6 web template builds failed missing in , prompting finding this issue) Emscripten 3.1.51 seems to be compatible with the LLVM 18.1.5 currently in nixpkgs unstable. Emscripten 3.1.59 (current as of this comment) and 3.1.57 are not compatible with that version of LLVM (In my usage, ran into errors with and ). These flags were introduced in Emscripten 3.1.55 making the last compatible version against the current in-tree dependencies 3.1.54. <details<summaryThis override was able to successfully build the godot4.3dev6 web templates using Emscripten 3.1.54</summary<p</p</details
Change:
homepage = "https://www.ponylang.org"; license = licenses.bsd2; maintainers = with maintainers; [ kamilchm patternspandemic redvers ]; <del> platforms = [ "x86_64-linux" "x86_64-darwin" ]; </del> <ins> platforms = [ "x86_64-linux" "x86_64-darwin" "aarch64-linux" ]; </ins> }; })

Discussion:
Steps to reproduce the behavior: ponyc (or, actually - don't) Can be seen here: - but in summary: The new kernel headers removed DECNet and libponyrt had a dependency on it. The excellent opened a PR against ponyc to remove that dependency which was merged an in the current release. OHHAI (Note: I will be raising a PR to fix this in the next few hours)
Change:
"password sufficient ${pam_krb5}/lib/security/pam_krb5.so use_first_pass"} ${optionalString config.services.samba.syncPasswordsByPam "password optional ${pkgs.samba}/lib/security/pam_smbpass.so nullok use_authtok try_first_pass"} <ins> ${optionalString cfg.enableGnomeKeyring "password optional ${pkgs.gnome3.gnome-keyring}/lib/security/pam_gnome_keyring.so use_authtok"} </ins> # Session management. ${optionalString cfg.setEnvironment ''

Discussion:
GDM's PAM modules are currently built so that the password stack of the keyring PAM module get loaded before a password input module is loaded, which results in the keyring never being unlocked automatically. in with GDM to use an application that has its password stored in GNOME keyring will ask you for the unlock password System: (Flounder) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: 16.09.1465.
Relevant discussion on unified PAM settings
Same with LightDM.
Automatic GNOME keyring unlocking with LightDM is fixed in NixOS 18.03, but GDM still does not unlock the keyring...
I wonder if this is resolved after
If it is a PAM thing, I do not thinks so. We did not touch PAM.

GDM currently uses custom PAM configuration that doesn't cover all items that are generated when is used, especially for sessions. As a result, logging in via GDM doesn't apply custom limits set via . custom limits that apply to the current user via out and back in again (via GDM) output output again, compare System: 16.09.1066. (Flounder) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: 16.09.1066.
Also facing this issue.
Closing in favor of open PR.
Change:
, python3 }: <del> python3.pkgs.buildPythonApplication rec { </del> <ins> let python = python3.override { packageOverrides = self: super: { rich = super.rich.overrideAttrs (old: rec { version = "12.4.0"; src = fetchFromGitHub { owner = "Textualize"; repo = "rich"; rev = "refs/tags/v${version}"; hash = "sha256-ryJTusUNpvNF2031ICJWK8ScxHIh+LrXYg7nd0ph4aQ="; }; }); textual = super.textual.overrideAttrs (old: rec { version = "0.1.18"; src = fetchFromGitHub { owner = "Textualize"; repo = "textual"; rev = "refs/tags/v${version}"; hash = "sha256-XVmbt8r5HL8r64ISdJozmM+9HuyvqbpdejWICzFnfiw="; }; }); }; }; in python.pkgs.buildPythonApplication rec { </ins> pname = "rich-cli"; version = "1.8.0"; format = "pyproject";

Discussion:
Steps to reproduce the behavior: Rich starts its pager Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(anselmschueler): nixpkgs:
This issue occurs because rich-cli isn't compatible with the newer rich version we have in nixpkgs. I'm not sure what the go is here as rich-cli hasn't been updated for a while (since Jun 21, 2022).
Ah, interesting. Maybe we should remove ?
I've done some more troubleshooting and the only thing I can find that doesn't seem to work is . If another issue comes up I'll mark it as broken, but I don't think this breaks the whole package as piping into another pager works fine.
I'd argue it is core functionality as from what I can gather it isn't just piping to your pager program but using a rich-specific pager.
Change:
sha256 = "1rcvxxcz2q7kgf6qbcjnjhysnx9z81hvl0jfv0nkp0p1w8bf1h66"; }; <del> nativeBuildInputs = [ makeWrapper ]; </del> <ins> nativeBuildInputs = [ makeWrapper wrapGAppsHook ]; buildInputs = [ glib ]; </ins> dontConfigure = true; dontBuild = true; dontPatchELF = true; <ins> dontWrapGApps = true; </ins> installPhase = let rpath = lib.makeLibraryPath [

Discussion:
When trying to attach a file to a secret, 1password exits with an error: Steps to reproduce the behavior: 1password a password to attach a file File dialog opens If applicable, add screenshots to help explain your problem. I managed to solve it (in a pretty much trial and error, not fully understanding) by overriding the attributes as described here: also adding gtk to the buildInputs: The file open dialog shows but it's not the same as in the rest of the system <!-- 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:
url = "https://gitlab.freedesktop.org/mesa/mesa/commit/aebbf819df6d1e.patch"; sha256 = "17248hyzg43d73c86p077m4lv1pkncaycr3l27hwv9k4ija9zl8q"; }) <ins> # For RISC-V support: (fetchpatch { name = "add-riscv-default-selections.patch"; url = "https://gitlab.freedesktop.org/mesa/mesa/-/commit/9908da1b7a5eaf0156d458e0e24b694c070ba345.patch"; sha256 = "036gv95m5gzzs6qpgkydf5fwgdlm7kpbdfalg8vmayghd260rw1w"; }) </ins> ] ++ optionals (stdenv.isDarwin && stdenv.isAarch64) [ # Fix aarch64-darwin build, remove when upstreaam supports it out of the box. # See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1020

Discussion:
Describe the bug VAAPI records repeated frames (see upstream bug report). upstream fix: To Reproduce Steps to reproduce the behavior: ... open OBS ... try recording using VAAPI (possible AMD hardware required?) ... watch replay Expected behavior full FPS. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
As for 21.0, the fix contained in upstream release = 21.0.2 so e.g. PR
Sadly a look at that thread, it's blocked because something broke, and they're not pushing it to 21.05, so this bug is going to exist until someone figures this out the regression, this patch is only one line of code, maybe it can be supplied as a patch until they get 21.0.3 working? Is there a way to build a patched mesa without rebuilding my entire desktop stack? It's currently stupidly slow on my computer when doing a packageOverride.
This will not be the only bug people will have to deal with on 21.05 unless we backport a more recent mesa (=21.1). Alternative we could also start to includes as well. Without it, this will lead to crashes in wine (incl. steam proton) when on some hardware ( for reference). While one can set as a workaround, it is hardly ideal and difficult to diagnose from within steam alone. Would it be possible to backport the mesa update currently in staging-next () once it is merged?
I don't know... this is hard. Maybe after a version has been a couple weeks in , we might be sufficiently confident that it won't make things worse overall.
I'm okay with backporting it, but probably as its own job set, just to get a better idea of regressions.
I'm not afraid of build-time regressions in this case. Those would be easy (to find). And mesa isn't such a big rebuild now anyway.
If it's been on unstable for a while, I guess I'm okay with it as well
I guess we can close this now, I haven't noticed any problems recently.
Change:
${occ}/bin/nextcloud-occ config:system:delete trusted_domains ${optionalString (cfg.extraAppsEnable && cfg.extraApps != { }) '' <del> # Try to enable apps (don't fail when one of them cannot be enabled , eg. due to incompatible version) </del> <ins> # Try to enable apps </ins> ${occ}/bin/nextcloud-occ app:enable ${concatStringsSep " " (attrNames cfg.extraApps)} ''}

Discussion:
the script is failing on . it appears that despite , we actually are "fail[ing] when one of them cannot be enabled". have configured, e.g. make a change, like a new version, that triggers an upgrade [recte ]. run , and see that the configuration change took place, but that the service run failed: It seems like running or , such that we are actually ignoring the failures would resolve this, but I am unclear on the implications of the flag: "enable the app regardless of the Nextcloud version requirement".
I do not think passing the option is the correct fix, going by that comment. To me, that means simply ignore any errors.
agreed, the root cause for this issue were some masked log lines. not sure if there is a great way to improve things, since this is definitely a reading comprehension issue, thus I will go ahead and close this.
I think there is still a bug, because the code and comment disagree with each other.
Change:
${optionalString cfg.startDbusSession '' if test -z "$DBUS_SESSION_BUS_ADDRESS"; then <del> exec ${pkgs.dbus.dbus-launch} --exit-with-session "$0" "$@" </del> <ins> ${config.systemd.package}/bin/systemctl --user start dbus.socket </ins> fi ''}

Discussion:
Describe the bug The dbus service doesn't seem properly started when lightdm+i3 is used. To Reproduce Expected behavior Doing the same within an lightdm+i3 session results in: Notify maintainers /cc Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
In the session running lightdm+i3, I can see: In the session running Gnome, I can see:
Here is some info about the user's unit:
I don't know if it's helpful, but I also get this on SDDM+Plasma5. This on the other hand works:
Change:
#shellcheck shell=bash set -eu -o pipefail <del> dirname="$(dirname "$0")" </del> <ins> cd "$(dirname "$0")" nixpkgs=../../../../. </ins> err() { echo "$*" >&2

Discussion:
Package name:warp-terminal Latest released version: <!-- Search your package here: --- Current version on the unstable channel:v0.2024.03.12.08.02.stable01 Current version on the stable/release channel:0.2023.11.07.08.02.stable00 <!-- 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:
/* Recursively find all packages (derivations) in `pkgs` matching `cond` predicate. <del> Type: packagesWithPath :: AttrPath → (AttrPath → derivation → bool) → (AttrSet | List) → List<AttrSet{attrPath :: str; package :: derivation; }> </del> <ins> Type: packagesWithPath :: AttrPath → (AttrPath → derivation → bool) → AttrSet → List<AttrSet{attrPath :: str; package :: derivation; }> </ins> AttrPath :: [str] The packages will be returned as a list of named pairs comprising of:

Discussion:
Describe the bug Automatically updating fails with the error message shown below. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The issue seems to be with the attributes , and , which are defined as lists of packages. If they are commented out the update command works. cc for comment.
Weird, I though I have removed support for lists, since they are incompatible with passing attribute path to the update scripts through . Must have gotten lost during rebase. should fix that.
Change:
with stdenv.lib; let <del> common = args@{ version, sha256, patches ? [] }: stdenv.mkDerivation rec { </del> <ins> common = args@{ version, sha256, patches ? [], withDocs ? false }: stdenv.mkDerivation rec { </ins> name = "openssl-${version}"; src = fetchurl {

Discussion:
The .out path contains about 18MB of html docs
To clarify, openssl10 does not, so this is a regression in that sense.
Change:
--replace '$'{prefix}/'$'{CMAKE_INSTALL_INCLUDEDIR} '$'{CMAKE_INSTALL_FULL_INCLUDEDIR} ''; <del> meta = with lib; { </del> <ins> postBuild = '' # From https://gitlab.archlinux.org/archlinux/packaging/packages/zeromq/-/blob/main/PKGBUILD # man pages aren't created when using cmake # https://github.com/zeromq/libzmq/issues/4160 pushd ../doc for FILE in *.txt; do asciidoc  -d manpage  -b docbook  -f asciidoc.conf  -a zmq_version="${finalAttrs.version}"  "''${FILE}" xmlto --skip-validation man "''${FILE%.txt}.xml" done popd ''; postInstall = '' # Install manually created man pages install -vDm644 -t "$out/share/man/man3" ../doc/*.3 install -vDm644 -t "$out/share/man/man7" ../doc/*.7 ''; passthru.tests = { inherit azmq cppzmq czmq zmqpp ; pyzmq = python3.pkgs.pyzmq; ffmpeg = ffmpeg.override { withZmq = true; }; }; meta = { </ins> branch = "4"; homepage = "http://www.zeromq.org"; description = "Intelligent Transport Layer"; <del> license = licenses.mpl20; platforms = platforms.all; maintainers = with maintainers; [ fpletz ]; </del> <ins> license = lib.licenses.mpl20; platforms = lib.platforms.all; maintainers = with lib.maintainers; [ fpletz ]; </ins> }; <del> } </del> <ins> }) </ins>

Discussion:
The package providing is missing several features that other distributions enable by default. Some examples: Upstream Debian Packaging: Arch Linux Packaging: Fedora Packaging: Features like and should probably be enabled by default. I was expecting curve support from the package and even saw in the package's inputs, yet I ran into an on . See the unused input: See the ENOTSUP error here: An we should probably provide build options similar to the upstream RHEL packaging. See Most should probably be enabled by default. <!-- 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]:
I can work on this tomorrow, but I'd rather follow what : Certainly we need to enable the flag to use . About CurveZMQ, I'd say the best option is to provide an input flag as that can be overridden by those who prefer it.
Since we depend on anyway I don't think there is any harm in enabling CurveZMQ by default - even without a flag. Are there negative side effects when enabling CurveZMQ?
Sorry, I was confusing the CurveCP protocol, which is supported by enabling , with CurveZMQ, which is a CurveCP implementation but its a whole different library that depends on . There is no flag related to CurveZMQ on ZeroMQ. But we do need to enable the flag to build with CurveCP support. Yes, sure, if the flag doesn't apply to Nix then it will not be considered.
(Why it wasn't closed automatically if it was linked?)
Change:
<ins> Partially reverts <https://codereview.qt-project.org/#/c/140954/>. diff --git i/mkspecs/features/qt_module.prf w/mkspecs/features/qt_module.prf index bb28af97..36bb6483 100644 --- i/mkspecs/features/qt_module.prf +++ w/mkspecs/features/qt_module.prf @@ -245,7 +245,7 @@ load(qt_installs) load(qt_targets) # this builds on top of qt_common -!internal_module:!lib_bundle:if(unix|mingw) { +!internal_module:if(unix|mingw) { CONFIG += create_pc QMAKE_PKGCONFIG_DESTDIR = pkgconfig host_build:  </ins>  No newline at end of file

Discussion:
QT5 for MacOS is not installing the correct files for pkg-config to work: macos: linux: /cc