jiebi/CodeConvo huggingface dataset:
Change:
</listitem> <listitem> <para> <ins> The <literal>wordpress</literal> service now takes configuration via the <literal>services.wordpress.sites.&lt;name&gt;.settings</literal> attribute set, <literal>extraConfig</literal> is still available to append additional text to <literal>wp-config.php</literal>. </para> </listitem> <listitem> <para> </ins> To reduce closure size in <literal>nixos/modules/profiles/minimal.nix</literal> profile disabled installation documentations and manuals. Also

Discussion:
Some wordpress applications, , assume this variable is present, even if they do not use it. I am unclear if this is undefined behaviour or a convention, but I have had to set to get wordpress to not crash after activating the plugin. Could we use or as the fallback, instead of leaving it undefined? Steps to reproduce the behavior: Please run and paste the result.
We should check what the Wordpress installer does in this case and if is usually written into
I have not manually tested it, but as best as I can grok, they set whatever the user provides, so seems more canonical?
Tested in a VM and you're right, setting DB_PASSWORD to '' seems to be the default case ! We should fix that and add a comment in the Wordpress module that this is the default behavior. Thanks for pointing that issue out!
Trying to fix this in this PR
Change:
<ins> { lib , stdenv , fetchFromGitHub , fish , runtimeShell , writeShellScript }: stdenv.mkDerivation rec { pname = "oh-my-fish"; version = "7+unstable=2021-03-03"; src = fetchFromGitHub { owner = pname; repo = pname; rev = "0b1396ad7962073fa25615bf03c43b53eddc2d56"; hash = "sha256-lwMo4+PcYR9kYJPWK+ALiMfBdxFSgB2vjtSn8QrmmEA="; }; buildInputs = [ fish ]; dontConfigure = true; dontBuild = true; installPhase = '' runHook preInstall mkdir -pv $out/bin $out/share/${pname} cp -vr * $out/share/${pname} cat << EOF > $out/bin/omf-install #!${runtimeShell} ${fish}/bin/fish  $out/share/${pname}/bin/install  --noninteractive  --offline=$out/share/${pname} EOF chmod +x $out/bin/omf-install runHook PostInstall ''; meta = with lib; { homepage = "https://github.com/oh-my-fish/oh-my-fish"; description = "The Fish Shell Framework"; longDescription = '' Oh My Fish provides core infrastructure to allow you to install packages which extend or modify the look of your shell. It's fast, extensible and easy to use. ''; license = licenses.mit; maintainers = with maintainers; [ AndersonTorres ]; platforms = fish.meta.platforms; }; } # TODO: customize the omf-install script </ins>

Discussion:
Project description Oh My Fish provides core infrastructure to allow to install packages which extend or modify the look of fish shell. It's fast, extensible and easy to use. Very similar to Oh-my-zsh that is already in NixOs package repo Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin,
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Any news on this?
I am still trying to understand how oh-my-zsh works.
Well, it just looks like a copy-paste. Just a giant install phase. <details<summaryTREE</summary</details
Isn't this issue about oh-my-fish instead of zsh?
Yes, it is. And I am studying oh-my-zsh in order to use it as a "template".
Change:
let cfg = config.xdg.portal; packages = [ pkgs.xdg-desktop-portal ] ++ cfg.extraPortals; <del> joinedPortals = pkgs.symlinkJoin { </del> <ins> joinedPortals = pkgs.buildEnv { </ins> name = "xdg-portals"; <del> paths = cfg.extraPortals; </del> <ins> paths = packages; pathsToLink = [ "/share/xdg-desktop-portal/portals" "/share/applications" ]; </ins> }; <del> in mkIf cfg.enable { </del> <ins> in mkIf cfg.enable { </ins> assertions = [ <del> { assertion = (cfg.gtkUsePortal -> cfg.extraPortals != []); message = "Setting xdg.portal.gtkUsePortal to true requires a portal implementation in xdg.portal.extraPortals such as xdg-desktop-portal-gtk or xdg-desktop-portal-kde."; </del> <ins> { assertion = cfg.extraPortals != [ ]; message = "Setting xdg.portal.enable to true requires a portal implementation in xdg.portal.extraPortals such as xdg-desktop-portal-gtk or xdg-desktop-portal-kde."; </ins> } ]; <del> services.dbus.packages  = packages; </del> <ins> services.dbus.packages = packages; </ins> systemd.packages = packages; <del> environment.sessionVariables = { GTK_USE_PORTAL = mkIf cfg.gtkUsePortal "1"; XDG_DESKTOP_PORTAL_DIR = "${joinedPortals}/share/xdg-desktop-portal/portals"; </del> <ins> environment = { # fixes screen sharing on plasmawayland on non-chromium apps by linking # share/applications/*.desktop files # see https://github.com/NixOS/nixpkgs/issues/145174 systemPackages = [ joinedPortals ]; pathsToLink = [ "/share/applications" ]; sessionVariables = { GTK_USE_PORTAL = mkIf cfg.gtkUsePortal "1"; XDG_DESKTOP_PORTAL_DIR = "${joinedPortals}/share/xdg-desktop-portal/portals"; }; </ins> }; }; }

Discussion:
When in a KDE wayland session with pipewire enabled nor firefox nor OBS' pipewire screen sharing does not show. Weirdly only Spectacle works for screen capture. Steps to reproduce the behavior: KDE plasma session and fail to screen capture ! suggest "compiling in an environment with pipewire" but adding pipewire to does not fix this system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Does it work in chrome?
Sharing the full screen no, but individual windows can be shared without problems
Have you checked the build log? What is the output of ?
So the reason it's not making any effect is because it already includes pipewire in its buildDependencies.
Neither patching works
And patching wayland-protocols straight up gives infinite recursion
please add this to the waayland board
So here is what I've found following
Here my thoughts: is suspect,especially after also look suspect
Suggest that the screencast plugin is loaded
The seems to originate from
90% sure does not get reached.
I've opened a bug in kde
<delSemms like whatever qml is needed for screencast is not included </delNope that is normal
Overall it seems like the screen selection window does not get displayed for whatever reason despite
This seems to be the same problem that was previously discussed in and related issues? Guess it makes sense to continue here since that issue is pretty cluttered at this point + mostly sway-related.
Change:
#!/usr/bin/env nix-shell <del> #!nix-shell -i python3 -p </del> <ins> #!nix-shell -i python3 -p python3 </ins> import collections.abc import fileinput

Discussion:
Steps to reproduce the behavior: Seems like the bitwarden-cli entry disappeared so now I have to use: 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. --cc this is on master
It still exists for me, is there some way I can reproduce this? that aside, this works I'm not submiting this as a PR since we probably shouldn't do this if bitwarden-cli is still intended to be used
Use rather than .
Change:
buildPythonPackage rec { pname = "textacy"; <del> version = "0.11.0"; </del> <ins> version = "0.12.0"; </ins> disabled = pythonOlder "3.7"; src = fetchPypi { inherit pname version; <del> sha256 = "sha256-d/tyTCewoERA15iBv4H2LORFzgco15fnnN1sneeGuF4="; </del> <ins> sha256 = "2c92bdd6b47305447b64e4cb6cc43c11675f021f910a8074bc8149dbf5325e5b"; </ins> }; propagatedBuildInputs = [

Discussion:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
paths[glob_target] = composefs_path add_leading_directories(glob_target, attrs, paths) else:  # Without globbing <del> if mode == "symlink": </del> <ins> if mode == "symlink" or mode == "direct-symlink": </ins> composefs_path = ComposefsPath( attrs, # A high approximation of the size of a symlink

Discussion:
Locale module is the only place in nixpkgs that mentions etc entry type: overlay generation code acknowledges the existence only of the type (). The provided system configuration builds. Mentioning since they committed the overlay code. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Simply replacing with in the locale module makes the build succeed. reports the correct timezone, and the symlink correctly points to the selected timezone within the .
Ah, it's much more complicated than that. The reason why exists is because some apps try to read the timezone name directly from the symlink path itself (, ). While the solution above makes the provided system configuration build, Java applications will fallback to using UTC because they are unable to parse the timezone name from the generated symlink.
Change:
paths[glob_target] = composefs_path add_leading_directories(glob_target, attrs, paths) else:  # Without globbing <del> if mode == "symlink": </del> <ins> if mode == "symlink" or mode == "direct-symlink": </ins> composefs_path = ComposefsPath( attrs, # A high approximation of the size of a symlink

Discussion:
If I try to make my system perlless, my system rebuild fails. Steps to reproduce the behavior: the following module to your system configuration: The command succeeds. Commands: succeeds. I use flakes. <!-- 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]:
Odd, thought was meant to fix this. Perhaps more digging is needed.
What is the revision of nixpkgs that you are trying to build your system with? is merged without a 24.05 backport.
Per nix-info they're on 24.05 not unstable, so that makes sense. Is it backportable?
The PR itself is backportable, but I'm not sure if it complies with nixpkgs' .
Right, that's what I meant to ask - is it a breaking change? (i.e. is it possible for someone to rely on the old behaviour?) or simply a bugfix with low chance of regressions?
Is it not a breaking change because the option is marked as experimental (and also because the behavior before the PR was erroneous in the first place).
Fixed in .
Change:
version = "1.3.4"; src = fetchzip { url = "https://github.com/michaeleisel/zld/releases/download/${version}/zld.zip"; <del> sha256 = "1rzdcrky0dl9n7niv39a5gc7q7rwl8jv6h77nvm6gwdymkjf2973"; </del> <ins> sha256 = "sha256-w1Pe96sdCbrfYdfBpD0BBXu7cFdW3cpo0PCn1+UyZI8="; </ins> }; installPhase = ''

Discussion:
Steps to reproduce the behavior: <!-- 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. system: host os: multi-user?: sandbox: version: channels(cherryblossom): channels(root): nixpkgs:
Looks like the hash in is invalid somehow, and nobody caught it since OfBorg and Hydra don't build this package, and nobody built it on Darwin to make sure. How did you get , did you test building the package with that hash?
Hi, thanks for filing a PR to fix the hash, it appears that in my hurry to include this update, I forgot to add to the nix-prefetch-url call I made. Apologies for the inconvenience, I'll be more careful next time and actually check stuff works before rushing to get a PR in.
Change:
propagatedBuildInputs = [ oildev <del> python27.pkgs.configargparse </del> <ins> configargparse </ins> ]; postPatch = ''

Discussion:
fails with the error message: Steps to reproduce the behavior: install bats <details<summarynix profile install nixpkgs#bats --show-trace</summary</detailsupgrading bats fails with the same error (assuming one had installed it before) n.a. Please run and paste the result.
This will be fixed by
Change:
echo "Wrapping $f" wrapProgram "$f"  "''${gappsWrapperArgs[@]}"  <del> "''${qtWrapperArgs[@]}"  --suffix LD_LIBRARY_PATH : "$runtimeLibPath" </del> <ins> "''${qtWrapperArgs[@]}" </ins> done ''; }

Discussion:
Describe the bug When open any component of wps office, it shows an dialog "An error has occurred in WPS" and crash. No logs found, but it works by using steam-run. To Reproduce Steps to reproduce the behavior: package pkgs.wpsoffice it in terminal or click office logo shows an error dialog, self-restart repeatedly and exit. Screenshots ! Notify maintainers Metadata `` Maintainer information:
Confirmed this error on my nixos
Change:
, qtwebengine , qtx11extras , qtquickcontrols2 <ins> , qtgraphicaleffects </ins> , getconf , glibc , libXrandr

Discussion:
After installing the update for TeamViewer 15.49.2 (introduced in ) I can no longer connect to remote hosts. The connection is established, but the window does not appear. If i try to connect to the same host again, I receive the message that I already have a connection open. Looking at the logs, this might be the issue: TeamViewer was working as expected on another system that was running version 15.38. After the update of that system, the same problem appears. TeamViewer to any host new window appears to the same host again "you are already connected" appears Please run and paste the result.
I'm still facing the same issue using
Please add more information and reopen a new issue. Thanks
Change:
"determination" "json" "test_list_short" <ins> "test_skip_maintenance" </ins> ]; meta = with lib; { description = "Install and run Python applications in isolated environments"; mainProgram = "pipx"; <del> homepage = "https://github.com/pipxproject/pipx"; </del> <ins> homepage = "https://github.com/pypa/pipx"; </ins> changelog = "https://github.com/pypa/pipx/blob/${version}/CHANGELOG.md"; license = licenses.mit; maintainers = with maintainers; [ yshym ];

Discussion:
Attempt to build pipx on nixos unstable Seems newer version of pipx has this new test "testskipmaintenance" that attempts to pip install a package, which fails due to the network-sandboxed build environment. This causes the build to fail altogether. Hence, "testskipmaintenance" should be to the list in Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
its only "testskipmaintenance" that is missing, the build was successful after i figured out how overridePythonAttrs worked, im new to nix.
Change:
<del> { lib, fetchFromGitHub, buildPythonApplication, aiohttp, python-dateutil, humanize, click, pytestCheckHook, tox }: </del> <ins> { lib, fetchFromGitHub, python3, }: </ins> <del> buildPythonApplication rec { </del> <ins> python3.pkgs.buildPythonApplication rec { </ins> pname = "twtxt"; version = "1.3.1"; <ins> pyproject = true; </ins> src = fetchFromGitHub { owner = "buckket"; <del> repo = pname; </del> <ins> repo = "twtxt"; </ins> rev = "refs/tags/v${version}"; sha256 = "sha256-CbFh1o2Ijinfb8X+h1GP3Tp+8D0D3/Czt/Uatd1B4cw="; }; <del> # Relax some dependencies postPatch = '' substituteInPlace setup.py  --replace 'aiohttp>=2.2.5,<3' 'aiohttp'  --replace 'click>=6.7,<7' 'click'  --replace 'humanize>=0.5.1,<1' 'humanize' ''; </del> <ins> build-system = with python3.pkgs; [ setuptools ]; </ins> <del> propagatedBuildInputs = [ aiohttp python-dateutil humanize click ]; </del> <ins> dependencies = with python3.pkgs; [ aiohttp click humanize python-dateutil setuptools ]; nativeCheckInputs = with python3.pkgs; [ pytestCheckHook ]; </ins> <del> nativeCheckInputs = [ pytestCheckHook tox ]; </del> <ins> pythonImportsCheck = [ "twtxt" ]; </ins> disabledTests = [ <del> # Disable test using relative date and time "test_tweet_relative_datetime" </del> <ins> # Disable test using relative date and time "test_tweet_relative_datetime" </ins> ]; meta = with lib; { description = "Decentralised, minimalist microblogging service for hackers"; homepage = "https://github.com/buckket/twtxt"; <ins> changelog = "https://github.com/buckket/twtxt/releases/tag/v${version}"; </ins> license = licenses.mit; maintainers = with maintainers; [ siraben ]; mainProgram = "twtxt";

Discussion:
When we try to install twtxt package on environment.systempackages = with pkgs;[ twtxt ]; the twtxt application does not work with the output on the title. Steps to reproduce the behavior: this based on twtxt nixpkgs reference to run the equivalent to The result from command above should be But the output will be something like The steuptools needs to be referenced on propagatedBuildInputs, maybe another python applications have the same bug. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Could you please take a look at ? Feedback would be much appreciated as I'm not a user.
Change:
stdenv.mkDerivation rec { name = "fcitx-qt5-${version}"; <del> version = "1.0.5"; </del> <ins> version = "1.1.0"; </ins> src = fetchurl { url = "http://download.fcitx-im.org/fcitx-qt5/${name}.tar.xz"; <del> sha256 = "1pj1b04n8r4kl7jh1qdv0xshgzb3zrmizfa3g5h3yk589h191vwc"; </del> <ins> sha256 = "0r8c5k0qin3mz2p1mdciip6my0x58662sx5z50zs4c5pkdg21qwv"; </ins> }; nativeBuildInputs = [ cmake extra-cmake-modules pkgconfig ];

Discussion:
after a , fcitx cannot switch to mozc only in chromium. journalctl gives me System: (NixOS: , Ubuntu/Fedora: , ...) 09pre106117. (Hummingbird) Nix version: (run ) nix-env (Nix) 1.11.8 Nixpkgs version: (run ) "17.09pre106117." fcitx version: 4.2.9.1 Chromium 57.0.2987.133
Thanks for reporting! Will look into this.
Change:
license = licenses.mit; platforms = [ "x86_64-linux" ]; maintainers = with maintainers; [ hyphon81 ]; <del> # See https://github.com/NixOS/nixpkgs/pull/179912#issuecomment-1206265922. broken = true; </del> }; }

Discussion:
From what I could tell this was only mentioned in some comment of a closed PR. This is blocking me from wrapping up a flake for Invoke AI (a Stable Diffusion webui). Any help/advice would be appreciated. This was described on Discourse by :
What commit of nixpkgs are you using? I might have some cycles this weekend to spend on this.
Looks like the cause is an outdated version of cutensor. It appears cupy is the only dependent of that so hopefully an upgrade is simple. I am working on a patch now.
Change:
boot.kernelParams = ["console=tty1" "console=${serialDevice}"]; <ins> services.udev.extraRules = '' SUBSYSTEM=="cpu", CONST{arch}=="x86-64", TEST=="online", ATTR{online}=="0", ATTR{online}="1" ''; </ins> virtualisation.lxd.agent.enable = lib.mkDefault true; }; }

Discussion:
Incus allow CPU hotplugging, but the cores remain offline in the NixOS VM image. Steps to reproduce the behavior: launch images:nixos/unstable nixos-cpu-hotplug config set nixos-cpu-hotplug 2 shell nixos-cpu-hotplog online state of CPU cores, e.g., using htop or the sysfs Hot plugged CPU cores need to be brought online to become usable. If applicable, add screenshots to help explain your problem. Installing the following rule sets hotplugged CPU online. The question that remains is whether to have the rules downstream or try to bring them upstream. I tested Ubuntu 24.04 for example, and they didn't have udev rules for that as well, so the ecosystem would likely benefit. <!-- 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:
builtins.mapAttrs (pname: attrs: callPackage ./generic.nix (attrs // { inherit pname; })) { zettlr = { <del> version = "3.0.2"; hash = "sha256-xwBq+kLmTth15uLiYWJOhi/YSPZVJNO6JTrKFojSDXA="; </del> <ins> version = "3.2.0"; hash = "sha256-gttDGWFJ/VmOyqgOSKnCqqPtNTKJd1fmDpa0ZAX3xc8="; </ins> }; }

Discussion:
Since Zettlr is an Electron app, it needs to be run with certain command-line arguments on Wayland (specifically ). In NixOS, setting the environment variable to should automatically tell packages to use this command-line argument, but this requires integrating it into the package file (see ) for an example. The Zettlr package does not currently do this, which results in pixelated and glitchy graphics on Wayland unless it is manually run with the correct command-line arguments. This should be a pretty simple fix, as it has been implemented before for many other Electron apps by creating a binary wrapper.
Change:
libusb1 libxkbcommon libxkbfile <del> libxslt </del> <ins> openh264 </ins> openssl orc <del> pcre </del> <ins> pcre2 </ins> pcsclite zlib <del> ] ++ lib.optionals stdenv.isLinux [ </del> <ins> ] ++ optionals stdenv.isLinux [ </ins> alsa-lib systemd wayland <del> ] ++ lib.optionals stdenv.isDarwin [ </del> <ins> ] ++ optionals stdenv.isDarwin [ </ins> AudioToolbox AVFoundation Carbon Cocoa CoreMedia <ins> ] ++ optionals withUnfree [ faac </ins> ]; <del> nativeBuildInputs = [ cmake pkg-config ]; </del> <ins> nativeBuildInputs = [ cmake libxslt docbook-xsl-nons pkg-config ]; </ins> doCheck = true; <del> cmakeFlags = [ "-DCMAKE_INSTALL_LIBDIR=lib" ] ++ lib.mapAttrsToList (k: v: "-D${k}=${if v then "ON" else "OFF"}") { BUILD_TESTING = doCheck; WITH_CUNIT = doCheck; </del> <ins> # https://github.com/FreeRDP/FreeRDP/issues/8526#issuecomment-1357134746 cmakeFlags = [ "-Wno-dev" "-DCMAKE_INSTALL_LIBDIR=lib" "-DDOCBOOKXSL_DIR=${docbook-xsl-nons}/xml/xsl/docbook" ] ++ lib.mapAttrsToList (k: v: "-D${k}=${cmFlag v}") { BUILD_TESTING = false; # false is recommended by upstream WITH_CAIRO = (cairo != null); </ins> WITH_CUPS = (cups != null); <ins> WITH_FAAC = (withUnfree && faac != null); WITH_FAAD2 = (faad2 != null); WITH_JPEG = (libjpeg_turbo != null); WITH_OPENH264 = (openh264 != null); </ins> WITH_OSS = false; WITH_PCSC = (pcsclite != null); WITH_PULSE = (libpulseaudio != null); WITH_SERVER = buildServer; <del> WITH_SSE2 = stdenv.isx86_64; WITH_VAAPI = true; WITH_JPEG = (libjpeg_turbo != null); WITH_CAIRO = (cairo != null); </del> <ins> WITH_VAAPI = false; # false is recommended by upstream </ins> WITH_X11 = true; };

Discussion:
I reported some flakey test in freerdp upstream and they hinted that maybe we could be building freerdp better: Filing this so I don't forget to look at it.
I use freerdp all the time, so I have patched things up on my side and will open a proper PR when I have been running with it for a while. FYI, we are in fact already building against ffmpeg.
Change:
-rm -f $(DESTDIR)$(datarootdir)/julia/base/version_git.sh -rm -f $(DESTDIR)$(datarootdir)/julia/test/Makefile -- <del> 2.42.0 </del> <ins> 2.43.0 </ins>

Discussion:
This is regarding hydra build failure. Thanks to a matrix user for pointing out the hydra link! Thank you! Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: