jiebi/CodeConvo huggingface dataset:
Change:
}: let <del> version = "1.10.8"; </del> <ins> version = "1.11.0"; </ins> pname = "session-desktop"; src = fetchurl { url = "https://github.com/oxen-io/session-desktop/releases/download/v${version}/session-desktop-linux-x86_64-${version}.AppImage"; <del> sha256 = "sha256-r/MQlZ3dmQmQZ/FCYIIF2sh9+VXwG97PFfTIXIQijx8="; </del> <ins> sha256 = "sha256-QartWtp5/OtJqQq5GXRoIQ/ytK9/YCW1ixXTUrnGwqw="; </ins> }; appimage = appimageTools.wrapType2 { inherit version pname src;

Discussion:
Package name: session-desktop Latest released version: 1.11.0 <!-- Search your package here: --- Current version on the unstable channel: 1.10.8 Current version on the stable/release channel: 1.10.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.
Change:
comment = "Code Editing. Redefined."; genericName = "Text Editor"; exec = executableName + " --open-url %U"; <del> icon = "code"; </del> <ins> icon = "vs${executableName}"; </ins> startupNotify = true; categories = [ "Utility" "TextEditor" "Development" "IDE" ]; mimeTypes = [ "x-scheme-handler/vscode" ];

Discussion:
VSCode/VSCodium's desktop icon (specified in the file) is set to . On the icon theme (the default dark icon theme that comes with Budgie desktop on NixOS), this makes it look like a generic text editor, and not the respective application. The issue appears to arise from how both apps use the same desktop files that were inherited from :   NixOS w/ Budgie desktop Icon theme to Qogir/Qogir-dark VSCodium/VSCode app list VSCode should use the icon VSCodium should use the icon ! My NixOS install is running in a VMWare VM.
Change:
src = ./strict_action_env.patch; strictActionEnvPatch = defaultShellPath; }) <ins> # bazel reads its system bazelrc in /etc # override this path to a builtin one (substituteAll { src = ./bazel_rc.patch; bazelSystemBazelRCPath = bazelRC; }) </ins> ] ++ lib.optional enableNixHacks ./nix-hacks.patch;

Discussion:
Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .
Change:
<ins> { python, stdenv }: with python.pkgs; buildPythonApplication rec { pname = "chkcrontab"; version = "1.7"; src = fetchPypi { inherit pname version; sha256 = "0gmxavjkjkvjysgf9cf5fcpk589gb75n1mn20iki82wifi1pk1jn"; }; meta = with stdenv.lib; { description = "A tool to detect crontab errors"; license = licenses.asl20; maintainers = with maintainers; [ ma27 ]; homepage = https://github.com/lyda/chkcrontab; }; } </ins>

Discussion:
It would be nice to see packaged such that at least an executable is exposed.
How about doing it yourself? Have a look at the and at the many examples in If you have questions, just ask them in this thread.
Change:
claws-mail-gtk3 = claws-mail; # Added 2021-07-10 clucene_core_1 = throw "'clucene_core_1' has been renamed to/replaced by 'clucene_core'"; # Added 2023-12-09 cntk = throw "'cntk' has been removed from nixpkgs, as it was broken and unmaintained"; # Added 2023-10-09 <del> code-server = throw "'code-server' has been removed from nixpkgs, as it was depending on EOL Node.js and is unmaintained."; # Added 2023-10-30 </del> codimd = hedgedoc; # Added 2020-11-29 inherit (libsForQt5.mauiPackages) communicator; # added 2022-05-17 compton = throw "'compton' has been renamed to/replaced by 'picom'"; # Converted to throw 2023-09-10

Discussion:
Currently, code-server (and openvscode-server) depends on 16 in nixpkgs, for the upcoming release of NixOS 23.11, this dependency must be dropped, and all upgrades must be performed to 18. From what I see on — 18 is supported as an engine. Otherwise, those programs are to be dropped. Please pick up the pieces cc
Drop will be performed in
Change:
set +x ''; <del> patches = optional enableHardening ./hardened.patch ++ [ ./qtx11extras.patch ]; </del> <ins> patches = optional enableHardening ./hardened.patch # https://www.virtualbox.org/pipermail/vbox-dev/2017-December/014888.html ++ optional headless [ ./HostServices-SharedClipboard-x11-stub.cpp-use-RT_NOR.patch ] ++ [ ./qtx11extras.patch ]; </ins> postPatch = '' sed -i -e 's|/sbin/ifconfig|${nettools}/bin/ifconfig|' 

Discussion:
virtualbox in headless mode currently doesn't compile on nixpkgs-unstable. results.
Seems they forget one file when converting from use of NOREF to their new RTNOREF[n] You could fix it like this (worked for me YMMV) mv src/VBox/HostServices/SharedClipboard/x11- src/VBox/HostServices/SharedClipboard/x11-; sed -e '/^[ ]NOREF([^,)]{1,})/ s/NOREF/RTNOREF1/' src/VBox/HostServices/SharedClipboard/x11- sed -e '/^[ ]NOREF([^,)]{1,},[^,)]{1,},[^,)]{1,},[^,)]{1,})/ s/NOREF/RT_NOREF4/' src/VBox/HostServices/SharedClipboard/x11-; diff -w src/VBox/HostServices/SharedClipboard/x11- src/VBox/HostServices/SharedClipboard/x11-;
Change:
}; extraConfig = '' index index.php index.html /index.php$request_uri; <del> add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; add_header X-Frame-Options sameorigin; add_header Referrer-Policy no-referrer; add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always; </del> <ins> ${optionalString (cfg.nginx.recommendedHttpHeaders) '' add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection "1; mode=block"; add_header X-Robots-Tag none; add_header X-Download-Options noopen; add_header X-Permitted-Cross-Domain-Policies none; add_header X-Frame-Options sameorigin; add_header Referrer-Policy no-referrer; add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always; ''} </ins> client_max_body_size ${cfg.maxUploadSize}; fastcgi_buffers 64 4K; fastcgi_hide_header X-Powered-By;

Discussion:
Describe the bug headers are set in with appendHttpConfig or extraConfig you only can add the same header again with another value but you can not replace the headers set in Expected behavior have an option to enable default headers and disable them to set them yourself Additional context specially for cache or content-security-policy headers annoying Notify maintainers
What about ?
might work but creates the need to check this options on every update.
What needs to be checked every update? Why?
i mean if there is a need for changes in this section.
Ah sorry, yes I understand.
Perhaps we can set headers in an RFC42-style way such as: This would be an addition that should be in the -module itself though. Unfortunately I already have way too much other todos right now, so I don't really want to start another (IMHO) non-trivial task here, so feel free to take over :)
Change:
example = "--max-freed $((64 * 1024**3))"; type = lib.types.singleLineStr; description = lib.mdDoc '' <del> Options given to {file}`nix-collect-garbage` when the garbage collector is run automatically. </del> <ins> Options given to [`nix-collect-garbage`](https://nixos.org/manual/nix/stable/command-ref/nix-collect-garbage) when the garbage collector is run automatically. </ins> ''; };

Discussion:
In the documentation of (stable and unstable), the option states the following: In the referenced documentation of (stable and unstable), two meanings of are described. The second one reads as follows: However, when e.g. is configured as , an error is returned. Used NixOS configuration: Log of : I'm not sure weather this is a documentation problem or a bug. We should either make it clear in the documentation, that with only can be used, or allow the usage of . <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
the documentation on is valid only for that command. The value of is passed to . As that manual page says, corresponds to , where is a fixed special value. It may be a bit confusing because you have to wire those different things up in your head while reading. Adding a few links would certainly help. But otherwise documentation and option behavior is correct.
Change:
- [zeronsd](https://github.com/zerotier/zeronsd), a DNS server for ZeroTier users. Available with [services.zeronsd.servedNetworks](#opt-services.zeronsd.servedNetworks). <ins> - [Collabora Online](https://www.collaboraonline.com/), a collaborative online office suite based on LibreOffice technology. Available as [services.collabora-online](options.html#opt-services.collabora-online.enable). </ins> - [wg-access-server](https://github.com/freifunkMUC/wg-access-server/), an all-in-one WireGuard VPN solution with a web ui for connecting devices. Available at [services.wg-access-server](#opt-services.wg-access-server.enable). - [Envision](https://gitlab.com/gabmus/envision), a UI for building, configuring and running Monado, the open source OpenXR runtime. Available as [programs.envision](#opt-programs.envision.enable).

Discussion:
Collabora Online Hi there, As of today, OnlyOffice is packaged in nixpkgs though it has a bug that throws SIG_ILL in x2t transformer. An alternative to onlyoffice, there is Collabora Online. It is an online version of libreoffice that can be integrated into several different portals suchs as nextcloud, moodle etc. I've decided to give it a go to package it into nixpkgs with the following shell: When I've tried to configure it looked for libreofficekit that which I am not familiar with. I've looked into the the libreoffice-collabora package and found only the followings: My question is, is it possible to get dev contents of libreoffice in nixpkgs via some output (usually it is 'dev')? I must admit I do not possess much experience with libreoffice and friends. I assume libreofficekit is a dev extension that can hook up to some functionality in libreoffice, please correct me if I am wrong. I think while the onlyoffice gets a proper fix, it is positive to initiate a conversation for an alternative that is collabora in this particular situtation. best, evrim. Metadata source URL:
Change:
checkPhase = '' xvfb-run dbus-run-session  --config-file=${dbus.daemon}/share/dbus-1/session.conf  <del> ${python3.interpreter} setup.py test </del> <ins> ${python3.interpreter} -m unittest discover -s test/unit -v ${python3.interpreter} -m unittest discover -s test/no_gui -v </ins> ''; # necessary for wrapGAppsHook

Discussion:
does not build in nixpkgs-unstable, nixos-21.11 and master. The test phase fails with python import errors for emoji data. Thus gajim seems broken in current NixOS and branches. Steps to reproduce the behavior: (current head of nixos-21.11) Gajim builds without any errors. Possibly introduced by Please run and paste the result. Maintainer information:
Looks like it builds now in and
I confirm that after updating I got Gajim back.
Yup, can confirm. Works again, now.
Change:
"--skip=pager_more" "--skip=pager_most" "--skip=pager_overwrite" <ins> # Fails if the filesystem performs UTF-8 validation (such as ZFS with utf8only=on) "--skip=file_with_invalid_utf8_filename" </ins> ]; doInstallCheck = true;

Discussion:
Steps to reproduce the behavior: a filesystem that doesn't accept non-utf8 characters (i.e. ) I think that this is a known issue with ZFS and darwin. There is precedent for this kind of issue in + and the consensus seems to be that it is acceptable to just disable such tests. Also, see . I have verified that adding to fixes the issue. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Upstream has already rejected fixing this in sharkdp/bat, so we'll have to keep this in nixpkgs or convince upstream to accept a fix.
I just tested this on a ZFS machine and I couldn't reproduce it, so yet again apples annoying filesystem strikes us. Please create a PR to skip this on darwin and check if that fixes your issue.
You have to create the dataset with the (or alternatively ) property enabled. This is not the default, however the official ZFS docs recommend this setting. Also you might need to have be in the same dataset instead of a . I am on NixOS, not Darwin, but one of the issues I linked claims that Darwin users are also sometimes affected by this problem (no relation to ZFS in that case). Ideally, we should disable this test for everyone since the choice of the filesystem is orthogonal to whether it's Darwin or NixOS or whatever. Sorry, if my original description wasn't clear.
I have that and normalization set to formD. I think I grabbed the one machine where I have this as the others have to little RAM. Good catch. Yeah, thanks for the explanations! Then we just disable it for everyone and be done with it.
Change:
#   /nix/store/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-podofo-0.9.6-dev/include/podofo/base/PdfVariant.h preFixup = '' remove-references-to -t ${podofo.dev}  <del> $out/lib/calibre/calibre/plugins${lib.optionalString pythonPackages.isPy3k "/3"}/podofo.so </del> <ins> $out/lib/calibre/calibre/plugins${lib.optionalString python3Packages.isPy3k "/3"}/podofo.so </ins> for program in $out/bin/*; do wrapProgram $program 

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: calibre <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 4.23.0 desired version: 5.6 <!-- 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:
stopIfChanged = false; }; <ins> boot.kernel.sysctl = mkIf (cfg.useRoutingFeatures == "server" || cfg.useRoutingFeatures == "both") { "net.ipv4.conf.all.forwarding" = mkDefault true; "net.ipv6.conf.all.forwarding" = mkDefault true; }; networking.firewall.checkReversePath = mkIf (cfg.useRoutingFeatures == "client" || cfg.useRoutingFeatures == "both") "loose"; </ins> networking.dhcpcd.denyInterfaces = [ cfg.interfaceName ]; systemd.network.networks."50-tailscale" = mkIf isNetworkd {

Discussion:
I really appreciate this message, but also would like to be able to disable it. Most of my Tailscale machines are not exit nodes, nor do they act as subnet routers, hence I would prefer to leave strict filtering enabled and also not have these warnings. It seems like a small thing, but these warnings tend to make me blind to other new, more relevant warnings. I'm hacking on something here:
Thanks for raising this, have been ignoring this issue for ages and meaning to try to do something about it but never got around to it :sweat_smile:
Hah now I'm going to ask you for feedback - how does sound for the option name? It's wordy but I can't think of anything much better. ? but then that hits the issue where it removes the chance for users to see / opt-out of future warnings.
sounds fine, not aware of any existing convention for options to silence warnings.
Change:
proper = buildHex { name = "proper"; <del> version = "1.1.1-beta"; </del> <ins> version = "1.4.0"; </ins> <del> sha256  = "0hnkhs761yjynw9382w8wm4j3x0r7lllzavaq2kh9n7qy3zc1rdx"; configurePhase = '' ${erlang}/bin/escript write_compile_flags include/compile_flags.hrl ''; </del> <ins> sha256  = "sha256-GChYQhhb0z772pfRNKXLWgiEOE2zYRn+4OPPpIhWjLs="; </ins> }; in

Discussion:
Package name: lfe (Lisp Flavored Erlang) Latest released version: 2.1.1 <!-- Search your package here: --- Current version on the unstable channel: 1.3 Current version on the stable/release channel: 1.3 <!-- 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.
Please test. Tracking: But you can use nixpkgs-review too. At nixpkgs git directory: -
Change:
version = "2019-08-10"; nativeBuildInputs = [ makeWrapper ]; <del> buildInputs = [ swiProlog ]; </del> <ins> buildInputs = [ swi-prolog ]; </ins> src = fetchFromGitHub { owner = "Attempto";

Discussion:
It seems that errors with when attempting to have in . There has been no updates in the lspserver. I came across this while trying to update my systems. Currently, says , so that was the last build I had with the lsp not causing a build failure. Steps to reproduce the behavior: this expression: It seems this started happening in . Works fine on the parent commit. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems adding to allows it to build, it is not clear to me how is being used here as I am not familiar with how packs work in swiProlog and why made this necessary. From looking at that commit in , it appears to be something that changed upstream. This builds:
I can confirm that with 9.1.21, swi-prolog + lsp-server builds just fine, even with the latest packaging. Something must indeed have changed upstream. 9.1.22 is the first version that stops building for me. The notes that the pack system got a refactor at that point, so that's probably what is going on here, but nothing indicates a sudden need for git. If git is now necessary for pack installation (even if we already pre-cloned everything) it should be a dependency. any idea why git became necessary here?
We can resolve this with a patch to SWI-Prolog to respect in the options, then adding that option to our invocation. I submitted a PR to SWI-Prolog (SWI-Prolog/swipl-devel). If upstream merges this, we can just apply the same patch to stable.
swi-prolog 9.2.7 backported the PR mentioned above. I've modified the package definition to supply the proper flag which suppresses git use during extraPacks install.
Change:
outbound = netCfg.firewall.outbound; }; } netCfg.settings; <del> configFile = format.generate "nebula-config-${netName}.yml" settings; </del> <ins> configFile = format.generate "nebula-config-${netName}.yml" ( warnIf ((settings.lighthouse.am_lighthouse || settings.relay.am_relay) && settings.listen.port == 0) '' Nebula network '${netName}' is configured as a lighthouse or relay, and its port is ${builtins.toString settings.listen.port}. You will likely experience connectivity issues: https://nebula.defined.net/docs/config/listen/#listenport '' settings ); </ins> in { # Create the systemd service for Nebula.

Discussion:
When a "lighthouse" and a regular "roaming" node are on the same network and the default value for () is used, nodes occasionally enter a consistent failure state while trying to connect. I suspect this occurs when Nebula tries to NAT-punch with the local router and always tries to connect to the lighthouse instead of the roaming node. Steps to reproduce the behavior: up a lighthouse node and roaming node -forward port 4242 for the lighthouse node to set a value for in the Nebula config intermittent failures The value of should be required, with a link to Nebula docs: I'm not entirely sure, but logs from the issue indicate the lighthouse-node handshakes are both sending packets to "192.168.1.1:4242", which is port-forwarded to the lighthouse (I'm in a dual-NAT setup unfortunately; this is the IP of the outer NAT). Explicitly setting the port to (to automatically select an ephemeral port) on the roaming nodes immediately fixes the issue. (wrote the initial module with the port default) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Based on those docs, I think we can solve this without requiring the user to specify the port. Since we know whether a node is a lighthouse via , we could implement a behavior where defaults to for lighthouses and for non-lighthouses: I'm not sure how to get the for this, though. Maybe if the options were , then we could just refer to ? We'd probably also want to include . Thoughts?
My thought is that a change should meet the following requirements: Per set and to something like:Set the actual value appropriately in the module with an expression like the above if the input is null. If (isLighthouse or isRelay) and the final port evaluates to 0, we should warn, since this config will probably result in connectivity issues. There should be a test for this. I am split on whether to backport this. While this is a bug, people may have relied on the default port to NAT port forward from routers to a Nebula node that is not a lighthouse or a relay.

As such the new default may impede connectivity on restrictive NATs, so this is also a breaking change.
Also, good job diagnosing this. I think I've run into this before but didn't know what was causing it.
Per (captured in + ) Given this, it is probably a good idea to both fix and backport this.