Question: </para> <section xml:id="module-services-mailman-basic-usage"> <del> <title>Basic usage</title> </del> <ins> <title>Basic usage with Postfix</title> </ins> <para> <del> For a basic configuration, the following settings are suggested: </del> <ins> For a basic configuration with Postfix as the MTA, the following settings are suggested: </ins> <programlisting>{ config, ... }: { services.postfix = { enable = true;

Describe the bug Mailman module in NixOS requires postfix enabled and has no way to configure Mailman to work with other MTAs supported by both NixOS and mailman upstream. To Reproduce Steps to reproduce the behavior: postfix mailman the evaluation with an assertion Expected behavior The Mailman module allows to select an MTA of choice (or even adapts to the currently enabled MTA) Screenshots n/a Additional context Notify maintainers cc Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(vika): nixpkgs: Maintainer information:
It looks like exim's configuration should be RFC42-ised first if we want to inject Mailman-related settings into Exim config, which is a requirement (Mailman requires a custom Exim router and transport).
Yes, the module is currently quite opinionated. If you're willing to contribute exim support that's great.
I see how I could make it work, but the first version of it will require manual editing of Exim's config files (because RFC42-ising Exim will be a pain, even though I have some drafts on how to translate Nix into the syntax that's required), and I'm not sure if it will be merge-worthy enough :3
Exim config is complicated enough as is, I'm not sure adding an intermediate layer from nix will help that much. I also don't really see this integrating well with existing or other exim config. I'm honestly kind of surprised this works for postfix.


Question: let pname = "pango"; <del> version = "1.43.0"; </del> <ins> version = "1.44.6"; </ins> in stdenv.mkDerivation rec { name = "${pname}-${version}"; src = fetchurl { url = "mirror://gnome/sources/${pname}/${stdenv.lib.versions.majorMinor version}/${name}.tar.xz"; <del> sha256 = "1lnxldmv1a12dq5h0dlq5jyzl4w75k76dp8cn360x2ijlm9w5h6j"; </del> <ins> sha256 = "0v7qq3fv1c0dl80d4qxsvd6cmhh4ngih3w0zc40f4dw7hfx427iy"; </ins> }; <ins> # 1.44.6-2 is not available from the usual mirrors yet, # so applying from gitlab patches = [ (fetchpatch { url = "https://gitlab.gnome.org/GNOME/pango/commit/8a408d4f25ddb0e3d6020cdde0cd8f8a19ee8db2.patch"; sha256 = "0l0hxwbijqrfvka302ijgih9jafc2ffs3d6d4v7bwynpn54lmza7"; }) ]; </ins> # FIXME: docs fail on darwin outputs = [ "bin" "dev" "out" ] ++ optional (!stdenv.isDarwin) "devdoc";

, (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
This is now fixed for 1.43 on master and 19.09:
Thanks :heart:


Question: <ins> { lib, buildPythonPackage, fetchPypi, orjson}: buildPythonPackage rec { pname = "fvs"; version = "0.3.4"; src = fetchPypi { inherit version; pname = "FVS"; extension = "tar.gz"; sha256 = "sha256-yYd0HzdwbqB9kexJjBRRYmdsoWtZtcjCNRz0ZJVM5CI="; }; propagatedBuildInputs = [ orjson ]; # no tests in src doCheck = false; pythonImportsCheck = [ "fvs" ]; meta = with lib; { description = "File Versioning System with hash comparison and data storage to create unlinked states that can be deleted"; homepage = "https://github.com/mirkobrombin/FVS"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

Vulkan/dxvk doesnt work on bottles. Vulkan is working correctly on my laptop as vkcube, vulkaninfo and the game im trying to run on bottles (that i ran thru wineWowPackages.staging + dxvk install from the official archive file) run perfectly. Steps to reproduce the behavior: bottles a bottle for gaming a game. the "directx error" pop up. Also, the dxvk log files say that the "VKKHRsurface" extension failed to load. DXVK/Vulkan should work on bottles. ! Please run and paste the result.
Having the exact same Issue on 22.11pre393800. (Raccoon)
If fails then there is a driver issue. Vulkan wont be able to draw anything to screen without it. When it occurs in proton issues it's usually a missing 32bit Vulkan library. Tho there can ofc probably be other causes
update: using the system wine doesn't fix dxvk either. only running thru the command line does. As i said, running it thru wine on the terminal does work, so something in the bottles thing is not working right.
I found the cause: these hardcoded paths right there: With this extra lines in , Vulkan will work on Bottles: I'm not sure if this is the best way to solve it, though. Tested only on a 64-bit bottle (I don't know if 32-bit bottles need to also link ). .
!!! nice find!


Question: <ins> { lib, buildPythonPackage, fetchPypi, orjson}: buildPythonPackage rec { pname = "fvs"; version = "0.3.4"; src = fetchPypi { inherit version; pname = "FVS"; extension = "tar.gz"; sha256 = "sha256-yYd0HzdwbqB9kexJjBRRYmdsoWtZtcjCNRz0ZJVM5CI="; }; propagatedBuildInputs = [ orjson ]; # no tests in src doCheck = false; pythonImportsCheck = [ "fvs" ]; meta = with lib; { description = "File Versioning System with hash comparison and data storage to create unlinked states that can be deleted"; homepage = "https://github.com/mirkobrombin/FVS"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

<!-- 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: bottles <!-- 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: 2022.5.28-trento-3 desired version: 2022.7.14-brescia-1 <!-- 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.
While automatic update using was removed by in you need to wait while we will "get auto updates from r-rynatm"
That not true. I removed the over complicated updater in which wasn't necessary at all. Since r-ryantm also uses nix-update there was also no need to replace it. That's wrong. You can always create an update PR yourself by running ` or by manually update the package and create a PR with that. r-ryantm goes through all packages so it can sometimes take a few days until the update PR is created. Also nix-update is very lightweight with minimal dependencies, so there is not really a reason to not use it. It also does not require any kind of token or authentication.
Bottles the version released after the one currently present in nixpkgs, was released on June 13. Over one month has passed, so something about the auto-updater isn't working.
The latest r-ryantm log is here . Not sure why that is not working like it should.
I guess a update script is needed for this case :disappointed: Since the package is using , it HAS a fallback update script , so nixpkgs-update is no longer trying to figure out the latest version itself but just run the script.


Question: <ins> { lib, buildPythonPackage, fetchPypi, orjson}: buildPythonPackage rec { pname = "fvs"; version = "0.3.4"; src = fetchPypi { inherit version; pname = "FVS"; extension = "tar.gz"; sha256 = "sha256-yYd0HzdwbqB9kexJjBRRYmdsoWtZtcjCNRz0ZJVM5CI="; }; propagatedBuildInputs = [ orjson ]; # no tests in src doCheck = false; pythonImportsCheck = [ "fvs" ]; meta = with lib; { description = "File Versioning System with hash comparison and data storage to create unlinked states that can be deleted"; homepage = "https://github.com/mirkobrombin/FVS"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

However seems like cannot handle the version , so it will fail at You may just try Repology gets software latest version from various Linux distributions that ships this app, so since AUR and OpenMandriva have 2022.6.14 (no suffix) the latest version is 2022.6.14. Looks like there is also an related report in Note that nixpkgs-update does not really tries to bump package in this way because it has an fallback update script.


Question: }; webapps = mkOption { <del> type = types.listOf types.package; </del> <ins> type = types.listOf types.path; </ins> default = [ tomcat.webapps ]; defaultText = "[ pkgs.tomcat85.webapps ]"; description = "List containing WAR files or directories with WAR files which are web applications to be deployed on Tomcat";

The option is declared as "list of packages". To me, it seems too restrictive, since it prevents useful configurations where web applications are copied from some mutable location in the filesystem, like this: . (Note that for tomcat's virtualHosts, the similar configurations are accepted and work fine just fine! I'm going to use them on my server.) Moreover, the current type was possibly chosen without much thought: it was a part of the long commit which mass- type specifications. My proposal is to change the type of from to . Right now, this kind of configuration produces an error: system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:


Question: weechat = assert lib.all (p: p.enabled -> ! (builtins.elem null p.buildInputs)) plugins; stdenv.mkDerivation rec { <del> version = "2.2"; </del> <ins> version = "2.3"; </ins> name = "weechat-${version}"; src = fetchurl { <del> url = "http://weechat.org/files/src/weechat-${version}.tar.bz2"; sha256 = "0p4nhh7f7w4q77g7jm9i6fynndqlgjkc9dk5g1xb4gf9imiisqlg"; </del> <ins> url = "https://weechat.org/files/src/weechat-${version}.tar.bz2"; sha256 = "0mi4pfnyny0vqc35r0scn6yy21y790a5iwq8ms7kch7b7z11jn9w"; </ins> }; outputs = [ "out" "man" ] ++ map (p: p.name) enabledPlugins;

3 is out! I'm not sure what's changed but it's at least 200% more better, and has a plugin for making you toast :stuckouttongue: . The release notes are here: and are as follows: Anyway I imagine someone'll be excited about the new version :grin: so thought I'd share.
Haha, a proper changelog is here: my bad :innocent:.


Question: <link linkend="opt-services.touchegg.enable">services.touchegg</link>. </para> </listitem> <ins> <listitem> <para> <link xlink:href="https://github.com/pantheon-tweaks/pantheon-tweaks">pantheon-tweaks</link>, an unofficial system settings panel for Pantheon. Available as <link linkend="opt-programs.pantheon-tweaks.enable">programs.pantheon-tweaks</link>. </para> </listitem> </ins> </itemizedlist> </section> <section xml:id="sec-release-21.11-incompatibilities">

Project description Pantheon Tweaks is a Switchboard plug allowing users to somewhat tweak Pantheon (elementary OS's DE) settings of the more hidden kind, not normally available from Switchboard. As NixOS has Pantheon packaged, it might be of use in Nixpkgs. Metadata homepage URL: source URL: license: platforms: same as Pantheon Depending on Pantheon version currently in Nixpkgs, the predecessor elementary-tweaks, also GPLv3, might be of more use:
As I maintain Pantheon in NixOS, I approve of this being packaged in the future, but not , because it's archived and IIRC I denied that .
Then we should probably do it once Pantheon in NixOS advances to whatever version elementary OS 6 Odin will have - this'll probably happen once elementary OS 6 will get released.
Ah yes, the repo says "Pantheon Tweaks is currently only supported on elementary OS Odin" :+1:
Did some initial work for this (), would you like to try that? Will need Pantheon 6 () and following line in your NixOS configuration file: Update: I will move this out from the pantheon namespace when creating the PR due to reasons below.
Did some initial work for this great! would you like to try that? of course works great. only the force darkmode did not work in minder program. haven't tested more... ! ! maybe it could be enabled by an option like ? So it's consistent with other options like .
Tested 1.13.1 on both elementary OS (installed via appcenter) and NixOS (btw minder in Nixpkgs seems out-of-date, just opened a PR: ), I guess this should be an issue to minder, as minder is trying to read information from of granite (, ), so it should respect settings from switchboard-plug-pantheon-shell, while what pantheon-tweaks does is (I guess) setting under you gtk config file and I am not sure how handle this. You can check this with: ! I am not sure as this is not an official part of Pantheon. I guess it should be okay to do this.
I am not sure as this is not an official part of Pantheon.


Question: <link linkend="opt-services.touchegg.enable">services.touchegg</link>. </para> </listitem> <ins> <listitem> <para> <link xlink:href="https://github.com/pantheon-tweaks/pantheon-tweaks">pantheon-tweaks</link>, an unofficial system settings panel for Pantheon. Available as <link linkend="opt-programs.pantheon-tweaks.enable">programs.pantheon-tweaks</link>. </para> </listitem> </ins> </itemizedlist> </section> <section xml:id="sec-release-21.11-incompatibilities">

yes, that is a concern, but we can make that clear in the description do you think it is acceptable to enable a third-party component (e.g. pantheon-tweaks) with an option like if we clarify that it is third-party in the description, which is for example displayed at the or in the documentation?
I would not recommend packaging this tweaks app. It regularly breaks since it references gsettings that aren't considered API. That's just my personal opinion though I'm not familiar with NixOS options or what that means so I can't really offer an opinion there
thanks for your opinion! the program exists and people want to use it and we at nixos want to empower users to do what they want, even if the choices could be considered bad, like installing proprietary software. that's why it's considered for advanced users. you are responsible for the choices you make and you can end up with a broken system, but it's easy to roll back to a working state. experimenting is encouraged So i think it's fine for us to offer the package, but we can clarify that "it's not recommended by elementary because it regularly breaks". I'm not familiar with NixOS options or what that means so I can't really offer an opinion there i try to explain quickly: on nixos the whole system is configured by one (or multiple) config. file. as a consequence is read-only if you want to use pantheon, you add this line to the config: that sets up pantheon with default settings. there are options to change those default, like to remove default apps you don't need... so the question here is, all current options with in the name relate to official pantheon software, but would relate to third party software, which is not visible from the name. so it might not be 100% clear all the time so my suggestion is to clarify it at least in the description of the option that it is third-party and not recommended the concern is that it could devaluate you branding like the name "pantheon"
ah okay yeah. If possible then it would great if that was not namespaced with actual parts of pantheon and instead namespaced the way you would hand extensions or apps if there's no special convention for extensions. Thanks!
i suggest then


Question: type = types.listOf (types.submodule { options = { name = mkOption { <del> type = types.listOf types.str; </del> <ins> type = types.str; </ins> description = "name of the virtualhost"; <ins> }; webapps = mkOption { type = types.listOf types.path; description = '' List containing web application WAR files and/or directories containing web applications and configuration files for the virtual host. ''; </ins> default = []; }; };

Commit introduced type specification for (which was absent before), but this specification is wrong. From within release-18.03, import the tomcat module from the master branch, and create a minimal Tomcat configuration that uses : And see it fails: When using the native module from release-18.03, everything works. system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:
It's only semi-related, but why on earth is the type of a list of packages, and not just a list of paths or strings?? It severely limits the configuration options for no apparent gain.
For the record, was an issue about overly restrictive type of .


Question: }, "libpng": { "url": "https://skia.googlesource.com/third_party/libpng.git", <del> "rev": "386707c6d19b974ca2e3db7f5c61873813c6fe44", "sha256": "sha256-67kf5MBsnBBi0bOfX/RKL52xpaCWm/ampltAI+EeQ+c=" </del> <ins> "rev": "144b348e072a78e8130ed0acc452c9f039a67bf2", "sha256": "sha256-eTF7q7hR4S1OqV2oPQKmcHujA5Od4rGMc5879kT0SkE=" </ins> } }

Package name: neovide Latest released version: 0.13.0 <!-- Search your package here: --- Current version on the unstable channel: 0.12.2 Current version on the stable/release channel: 0.11.2 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --- Note for maintainers: Please tag this issue in your PR. As an additional note, I am currently working on updating Neovide myself. Part of my plans this summer are to begin giving at least two contributions to Nix/NixOS/Nixpkgs each week. I intend to begin maintaining Neovide as part of this goal. Gotta figure out how to A.) apply as a maintainer and B.) figure out if I'm even eligible. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
For future issues/prs/etc. where should I add an additional summary/context if I have any? I've sandwiched it between the Note for maintainers... and Add a reaction... sections in this issue.


Question: # source code of the previous release to a different directory urls = [ "http://www.iram.fr/~gildas/dist/gildas-src-${srcVersion}.tar.xz" "http://www.iram.fr/~gildas/dist/archive/gildas/gildas-src-${srcVersion}.tar.xz" ]; <del> sha256 = "sha256-Eq6S5S8xrhkCo6O2wUaHnoMDVG9WeiSurGvOc+2JKbM="; </del> <ins> sha256 = "sha256-dZ03J3I1dgoSgSc9yGfO13ZvNawCSYKN3+SGvp1eyGA="; </ins> }; nativeBuildInputs = [ pkg-config groff perl getopt gfortran which ];

Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: <ins> { lib , stdenv , fetchgit , fetchFromGitHub , cmake , curl , nasm , libopenmpt , game-music-emu , libpng , SDL2 , SDL2_mixer , zlib , makeWrapper , makeDesktopItem , copyDesktopItems }: stdenv.mkDerivation (finalAttrs: { pname = "srb2"; version = "2.2.13"; src = fetchFromGitHub { owner = "STJr"; repo = "SRB2"; rev = "SRB2_release_${finalAttrs.version}"; hash = "sha256-OSkkjCz7ZW5+0vh6l7+TpnHLzXmd/5QvTidRQSHJYX8="; }; nativeBuildInputs = [ cmake nasm makeWrapper copyDesktopItems ]; buildInputs = [ curl game-music-emu libpng libopenmpt SDL2 SDL2_mixer zlib ]; assets = stdenv.mkDerivation { pname = "srb2-data"; version = finalAttrs.version; src = fetchgit { url = "https://git.do.srb2.org/STJr/srb2assets-public"; rev = "SRB2_release_${finalAttrs.version}"; hash = "sha256-OXvO5ZlujIYmYevc62Dtx192dxoujQMNFUCrH5quBBg="; fetchLFS = true; }; installPhase = '' runHook preInstall mkdir -p $out/share/srb2 cp -r * $out/share/srb2 runHook postInstall ''; }; cmakeFlags = [ "-DSRB2_ASSET_DIRECTORY=${finalAttrs.assets}/share/srb2" "-DGME_INCLUDE_DIR=${game-music-emu}/include" "-DOPENMPT_INCLUDE_DIR=${libopenmpt.dev}/include" "-DSDL2_MIXER_INCLUDE_DIR=${lib.getDev SDL2_mixer}/include/SDL2" "-DSDL2_INCLUDE_DIR=${lib.getDev SDL2.dev}/include/SDL2" ]; patches = [ # Make the build work without internet connectivity # See: https://build.opensuse.org/request/show/1109889 ./cmake.patch ./thirdparty.patch ]; desktopItems = [ (makeDesktopItem rec { name = "Sonic Robo Blast 2"; exec = finalAttrs.pname; icon = finalAttrs.pname; comment = finalAttrs.meta.description; desktopName = name; genericName = name; categories = [ "Game" ]; startupWMClass = ".srb2-wrapped"; }) ]; installPhase = '' runHook preInstall mkdir -p $out/bin $out/share/applications $out/share/pixmaps $out/share/icons copyDesktopItems cp ../srb2.png $out/share/pixmaps/. cp ../srb2.png $out/share/icons/. cp bin/lsdlsrb2 $out/bin/srb2 wrapProgram $out/bin/srb2 --set SRB2WADDIR "${finalAttrs.assets}/share/srb2" runHook postInstall ''; meta = with lib; { description = "Sonic Robo Blast 2 is a 3D Sonic the Hedgehog fangame based on a modified version of Doom Legacy"; homepage = "https://www.srb2.org/"; platforms = platforms.linux; license = licenses.gpl2Plus; maintainers = with maintainers; [ zeratax donovanglover ]; mainProgram = "srb2"; }; }) </ins>

use instead of pulling the windows zip from github releases
I can review if you want to PR this
upstream has said that they'd rather us use the github mirror that they're going to set up
the github mirror has been created
Sorry, I have to delete the github mirror, due to bandwidth limits. Please use
the "SRB22.2" branch and/or "SRB2release_2.2.13" tag
Getting 500 errors when trying to access
does this work for you?
The link works however the download buttons don't. PRs welcome if anyone can get it working, but wait for to be merged first to avoid merge conflicts.
i have had another look, and have found that it might be better to pull directly from branch
Thanks, was able to get it to work with :+1:


Question: <ins> diff --git a/bin/nexus b/bin/nexus index e7ed3fb..8db766b 100755 --- a/bin/nexus +++ b/bin/nexus @@ -440,7 +440,8 @@ add_class_path "$app_home/lib/boot/org.apache.karaf.diagnostic.boot-4.0.9.jar" add_class_path "$app_home/lib/boot/org.apache.karaf.jaas.boot-4.0.9.jar" vmoptions_val="" -read_vmoptions "$prg_dir/$progname.vmoptions" +VM_OPTS=${VM_OPTS_FILE:-"$prg_dir/$progname.vmoptions"} +read_vmoptions "$VM_OPTS" INSTALL4J_ADD_VM_PARAMS="$INSTALL4J_ADD_VM_PARAMS $vmoptions_val" </ins>

Package name: nexus Latest released version: 3.69.0 <!-- Search your package here: --- Current version on the unstable channel: 3.68.1-02 Current version on the stable/release channel: 3.68.1-02 <!-- 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]:


Question: <ins> diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index d910299e..69888477 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -99,6 +99,7 @@ endif() # Qt modules if (WITH_QT5) +    find_package(Qt5 REQUIRED COMPONENTS Network Svg Xml Script) qt5_use_modules(copyq Widgets Network Svg Xml Script ${copyq_Qt5_Modules}) else() set(QT_USE_QTNETWORK TRUE) </ins>

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


Question: , trezor-bridge, bluejeans, djview4, adobe-reader , google_talk_plugin, fribid, gnome3/*.gnome-shell*/ , esteidfirefoxplugin <del> , vlc_npapi </del> , browserpass, chrome-gnome-shell , libudev , kerberos

When trying to install firefox with , I get the following error: It seems is already gone on : Considering it doesn't work on 18.03 anyway, could we cherry-pick the commit to 18.03 to disable the VLC functionality? system: host os: multi-user?: sandbox: version: channels(sepp): channels(root): nixpkgs:
For whatever reason, on master I seem to be getting this error even without this (or other firefox configurations). So the issue could be broader than this. I suppose for you it worked after removing this option then?
This is now caused by another source on ; it should be fixed by (in branch, half of binaries built ATM).
The other issue is also fixed on master since .


Question: <ins> { lib , buildPythonPackage , hypothesis , fetchpatch , fetchPypi , setuptools , setuptools-scm , cloudpickle , cython , jinja2 , numpy , psutil , pynvml , pytestCheckHook , pythonOlder , rich }: buildPythonPackage rec { pname = "scalene"; version = "1.5.38"; pyproject = true; disabled = pythonOlder "3.9"; src = fetchPypi { inherit pname version; hash = "sha256-LR1evkn2m6FNBmJnUUJubesxIPeHG6RDgLFBHDuxe38="; }; patches = [ # fix scalene_config import. remove on next update (fetchpatch { name = "scalene_config-import-fix.patch"; url = "https://github.com/plasma-umass/scalene/commit/cd437be11f600ac0925ce77efa516e6d83934200.patch"; hash = "sha256-YjFh+mu5jyIJYUQFhmGqLXhec6lgQAdj4tWxij3NkwU="; }) ]; nativeBuildInputs = [ cython setuptools setuptools-scm ]; propagatedBuildInputs = [ cloudpickle jinja2 psutil pynvml rich ]; __darwinAllowLocalNetworking = true; nativeCheckInputs = [ pytestCheckHook ]; checkInputs = [ hypothesis numpy ]; disabledTestPaths = [ # remove on next update # Failing Darwin-specific tests that were subsequently removed from the source repo. "tests/test_coverup_35.py" "tests/test_coverup_42.py" "tests/test_coverup_43.py" ]; # remove scalene directory to prevent pytest import confusion preCheck = '' rm -rf scalene ''; pythonImportsCheck = [ "scalene" ]; meta = with lib; { description = "High-resolution, low-overhead CPU, GPU, and memory profiler for Python with AI-powered optimization suggestions"; homepage = "https://github.com/plasma-umass/scalene"; changelog = "https://github.com/plasma-umass/scalene/releases/tag/v${version}"; mainProgram = "scalene"; license = licenses.asl20; maintainers = with maintainers; [ sarahec ]; }; } </ins>

Project description Scalene is a high-performance CPU, GPU and memory profiler for Python that does a number of things that other Python profilers do not and cannot do. It runs orders of magnitude faster than many other profilers while delivering far more detailed information. It is also incorporates AI-powered optimization suggestions. Metadata homepage URL: source URL: license: Apache 2 platforms: unix, linux, darwin, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: virtualisation.diskSize = mkOption { <del> type = types.nullOr types.ints.positive; </del> <ins> type = types.ints.positive; </ins> default = 1024; description = '' The disk size in megabytes of the virtual machine.

Setting nixos option to null, which is legal according to typechecks results in an invalid disk size value passed to Launching the script, aka system build attribute , will throw an error at the disk creation stage mentioning an invalid argument for the size parameter. Steps to reproduce the behavior: new flake output attribute with value of basic nixosSystem option attribute ./result Launching ./result will create a qcow disk and launch qemu with the machine configuration. I found this bug through changes in nixos-generators. I've created an issue in their repo first, but their changes might be technically correct. REF; No maintainers list within that nixos module file. Pinging as last change author on the type of virtualisation.disksize. <!-- 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]:
I don't remember why I've set this option to . From the commit that it () it's clear that null is not handled, so it's probably a mistake.
Just stumbled upon this issue and agree with the analysis here. PR at


Question: <del> ../beta/disable-auto-update.patch </del>  No newline at end of file

When trying to install , the build fails with: To reproduce, use the following and run it with : I think this happens because of the symlink of the , which seems to be resolved while running the build and in that case the symlink target does not exist. /cc btw: could you please also add support for the latest beta / dev / stable releases?
Hey it's fixed in the latest commit. Can you try it ?
Works fine, thank you very much for the fast fix!


Question: <ins> *** a/Makefile  1970-01-01 01:00:01.000000000 +0100 --- b/Makefile  2022-06-21 23:36:10.023460654 +0200 *************** endif *** 109,110 **** --- 109,111 ---- LIBOPENAL = -lopenal + LIBOPENGL = -lGL RELEASE_NAME = linux </ins>

Project description Hashlink is a virtual machine used in Haxe/Heaps game projects. This is the same stack that shiro games and motion twin uses to make things like Dead Cells and Northgard. The full steps for installing heaps (which goes through dependencies) can be found , and one of the steps is to download hashlink and put it on the path. Metadata homepage URL: source URL: license: mit platforms: linux, mac, windows
I am on it, will try to compose a first draft. :-)
That was fast! I really appreciate it! I put in a few haxe-related package requests today, I'm so surprised no one else has requested them before! But once they're in we'll be happy! Not really looking to nix-ify my haxe projects yet since I imagine it'll be involved, but getting hashlink on the path in a package is a step in the right direction right? :) Really appreciate this, thank you!
I'm not really familiar with the Haxe ecosystem, but the Arch build for Hashlink suggested that this packaging task seemed simple enough (no complex build system, just a Makefile, no dependencies on other parts of the Haxe ecosystem) so that I could do it. Glad that I could be of help. :-) Thank you for your issue contributions! While the pull request is not yet merged, you can use hashlink as follows: (Be wary that commands like this can cause the execution of arbitrary code, so in principle one should use these only with trusted repositories.)
Thanks for your hard work!
how are things going with the PR? I think someone has asked a question on it, I don't know if that means that it's stalled from going in? Thanks again!
There are in fact issues with hashlink on NixOS I think - I think there's some libraries that are build with hashlink that are unhandled - there's an issue for this already as hinted in your PR:


Question: bazel_0_29 = callPackage ../development/tools/build-managers/bazel/bazel_0_29 { inherit (darwin) cctools; inherit (darwin.apple_sdk.frameworks) CoreFoundation CoreServices Foundation; <del> buildJdk = jdk8; </del> <ins> buildJdk = jdk8_headless; </ins> buildJdkName = "jdk8"; runJdk = jdk11_headless; stdenv = if stdenv.cc.isClang then llvmPackages_6.stdenv else stdenv;

Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in


Question: , gccForLibs ? if useCcForLibs then cc else null , fortify-headers ? null , includeFortifyHeaders ? null <del> # https://github.com/NixOS/nixpkgs/issues/295322 # should -march flag be used , disableMarch ? false </del> }: assert nativeTools -> !propagateDoc && nativePrefix != "";

Since was merged into the master, swift cannot be built on aarch64. Steps to reproduce the behavior: reported in I'm not familiar with swift or clang, but I'm using the following overlay as a workaround until it's fixed. <!-- 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]:
states that this only fixed the swift build but all downstream packages are still broken. re-opening.
Actually, it seems only dark-mode-notify is broken, others seem fine. Probably because it uses Cocoa or disables sandbox. I don't know for sure.
I noticed that my personal package does not build either. Maybe it's because of swift itself or swiftpm?
The above open PR seems to run into the same issue…


Question: shell = stdenv.shell; which = "${which}/bin/which"; dirname = "${coreutils}/bin/dirname"; <ins> realpath = "${coreutils}/bin/realpath"; </ins> }; } ./dotnet-fixup-hook.sh) { }; }

When running OmniSharp, the program is unable to find a dotnet runtime to use at all. When I remove the part from the part of the script, it starts to work. Presumably because moving the command to /dev/null just isn't helping at all? ! !
Oh this is an issue with buildDotnetModule. I was looking at nixos-23.05 when I am on nixos-unstable.
So I am not the only one having this issue I talked about this in the PR that introduced the bug (). I have made a proof of concept for a fix: I will open a PR for this, now that I know that I am not the only one experiencing this.
Your fix worked because, because the original code is checking whether you have dotnet installed by checking whether has an exit code of 0 (which it does, if it is installed). But if you change it to , it will always have exit code that is not 0 (because running is not correct by itself), thus making it think you don't have it installed, which means it will use the hardcoded dotnet 6 version instead.
Yeah, I just stumbled upon it while copy pasting the script manually, I didn't take the time to understand what was happening, still new to shell-scripts. Thanks for hopefully finding a solution!


Question: <del> { lib, stdenv, fetchurl, fetchpatch, gnu-efi, nixosTests }: </del> <ins> { lib , stdenv , fetchurl , gnu-efi , nixosTests , efibootmgr , openssl , sbsigntool , makeWrapper }: </ins> let archids = {

efibootmgr is not a dependency, despite being needed Steps to reproduce the behavior: refind refind-install the error message: ! efibootmgr is a dependency of refind I already had refind installed (from another distro) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: <ins> { config , lib , pkgs , ... }: let inherit (lib) mkDefault mkEnableOption mkIf mkOption mkPackageOption types; cfg = config.services.monado; in { options.services.monado = { enable = mkEnableOption "Monado user service"; package = mkPackageOption pkgs "monado" { }; defaultRuntime = mkOption { type = types.bool; description = '' Whether to enable Monado as the default OpenXR runtime on the system. Note that applications can bypass this option by setting an active runtime in a writable XDG_CONFIG_DIRS location like `~/.config`. ''; default = false; example = true; }; highPriority = mkEnableOption "high priority capability for monado-service" // mkOption { default = true; }; }; config = mkIf cfg.enable { security.wrappers."monado-service" = mkIf cfg.highPriority { setuid = false; owner = "root"; group = "root"; # cap_sys_nice needed for asynchronous reprojection capabilities = "cap_sys_nice+eip"; source = lib.getExe' cfg.package "monado-service"; }; services.udev.packages = with pkgs; [ xr-hardware ]; systemd.user = { services.monado = { description = "Monado XR runtime service module"; requires = [ "monado.socket" ]; conflicts = [ "monado-dev.service" ]; unitConfig.ConditionUser = "!root"; environment = { # Default options # https://gitlab.freedesktop.org/monado/monado/-/blob/4548e1738591d0904f8db4df8ede652ece889a76/src/xrt/targets/service/monado.in.service#L12 XRT_COMPOSITOR_LOG = mkDefault "debug"; XRT_PRINT_OPTIONS = mkDefault "on"; IPC_EXIT_ON_DISCONNECT = mkDefault "off"; }; serviceConfig = { ExecStart = if cfg.highPriority then "${config.security.wrapperDir}/monado-service" else lib.getExe' cfg.package "monado-service"; Restart = "no"; }; restartTriggers = [ cfg.package ]; }; sockets.monado = { description = "Monado XR service module connection socket"; conflicts = [ "monado-dev.service" ]; unitConfig.ConditionUser = "!root"; socketConfig = { ListenStream = "%t/monado_comp_ipc"; RemoveOnStop = true; # If Monado crashes while starting up, we want to close incoming OpenXR connections FlushPending = true; }; restartTriggers = [ cfg.package ]; wantedBy = [ "sockets.target" ]; }; }; environment.systemPackages = [ cfg.package ]; environment.pathsToLink = [ "/share/openxr" ]; environment.etc."xdg/openxr/1/active_runtime.json" = mkIf cfg.defaultRuntime { source = "${cfg.package}/share/openxr/1/openxr_monado.json"; }; }; meta.maintainers = with lib.maintainers; [ Scrumplex ]; } </ins>

The [monado] package doesn't install the udev rules generated by the [xr-hardware util] from the Monado project. Install the package and check the lack of udev rules in It was expected for the udev rules to be installted with the package. The udev rules are needed as some hmd's have some strange and specific permissions. Maybe instead of adding this to the package, monado could turn into an option like . <!-- 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]: [monado]: [xr-hardware util]:
Trying packaging the udev rules similar to how . [brscan4]:
I was working on a Monado NixOS module. Perhaps I can deal with udev rules there. See


Question: picom = callPackage ../applications/window-managers/picom {}; <ins> xd = callPackage ../applications/networking/p2p/xd {}; </ins> xdaliclock = callPackage ../tools/misc/xdaliclock {}; xdg-dbus-proxy = callPackage ../development/libraries/xdg-dbus-proxy { };

Project description homepage URL: https://xd- source URL: license: mit platforms: linux
I marked this as stale due to inactivity. →


Question: <ins> From: Sebastián Mancilla <smancill@smancill.dev> Subject: [PATCH] Fix compile errors when using Eigen 3.4 --- .../machine/gp/MultiLaplaceInferenceMethod.cpp | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/shogun/machine/gp/MultiLaplaceInferenceMethod.cpp b/src/shogun/machine/gp/MultiLaplaceInferenceMethod.cpp index 2e27678d2..60050afea 100644 --- a/src/shogun/machine/gp/MultiLaplaceInferenceMethod.cpp +++ b/src/shogun/machine/gp/MultiLaplaceInferenceMethod.cpp @@ -84,9 +84,9 @@ class CMultiPsiLine : public func_base float64_t result=0; for(index_t bl=0; bl<C; bl++) { -			eigen_f.block(bl*n,0,n,1)=K*alpha->block(bl*n,0,n,1)*CMath::exp(log_scale*2.0); -			result+=alpha->block(bl*n,0,n,1).dot(eigen_f.block(bl*n,0,n,1))/2.0; -			eigen_f.block(bl*n,0,n,1)+=eigen_m; +			eigen_f.segment(bl*n,n)=K*alpha->segment(bl*n,n)*CMath::exp(log_scale*2.0); +			result+=alpha->segment(bl*n,n).dot(eigen_f.segment(bl*n,n))/2.0; +			eigen_f.segment(bl*n,n)+=eigen_m; } // get first and second derivatives of log likelihood @@ -272,7 +272,7 @@ void CMultiLaplaceInferenceMethod::update_alpha() { Map<VectorXd> alpha(m_alpha.vector, m_alpha.vlen); for(index_t bl=0; bl<C; bl++) -			eigen_mu.block(bl*n,0,n,1)=eigen_ktrtr*CMath::exp(m_log_scale*2.0)*alpha.block(bl*n,0,n,1); +			eigen_mu.segment(bl*n,n)=eigen_ktrtr*CMath::exp(m_log_scale*2.0)*alpha.segment(bl*n,n); //alpha'*(f-m)/2.0 Psi_New=alpha.dot(eigen_mu)/2.0; @@ -316,7 +316,7 @@ void CMultiLaplaceInferenceMethod::update_alpha() for(index_t bl=0; bl<C; bl++) { -			VectorXd eigen_sD=eigen_dpi.block(bl*n,0,n,1).cwiseSqrt(); +			VectorXd eigen_sD=eigen_dpi.segment(bl*n,n).cwiseSqrt(); LLT<MatrixXd> chol_tmp((eigen_sD*eigen_sD.transpose()).cwiseProduct(eigen_ktrtr*CMath::exp(m_log_scale*2.0))+ MatrixXd::Identity(m_ktrtr.num_rows, m_ktrtr.num_cols)); MatrixXd eigen_L_tmp=chol_tmp.matrixU(); @@ -341,11 +341,11 @@ void CMultiLaplaceInferenceMethod::update_alpha() VectorXd tmp2=m_tmp.array().rowwise().sum(); for(index_t bl=0; bl<C; bl++) -			eigen_b.block(bl*n,0,n,1)+=eigen_dpi.block(bl*n,0,n,1).cwiseProduct(eigen_mu.block(bl*n,0,n,1)-eigen_mean_bl-tmp2); +			eigen_b.segment(bl*n,n)+=eigen_dpi.segment(bl*n,n).cwiseProduct(eigen_mu.segment(bl*n,n)-eigen_mean_bl-tmp2); Map<VectorXd> &eigen_c=eigen_W; for(index_t bl=0; bl<C; bl++) -			eigen_c.block(bl*n,0,n,1)=eigen_E.block(0,bl*n,n,n)*(eigen_ktrtr*CMath::exp(m_log_scale*2.0)*eigen_b.block(bl*n,0,n,1)); +			eigen_c.segment(bl*n,n)=eigen_E.block(0,bl*n,n,n)*(eigen_ktrtr*CMath::exp(m_log_scale*2.0)*eigen_b.segment(bl*n,n)); Map<MatrixXd> c_tmp(eigen_c.data(),n,C); @@ -409,7 +409,7 @@ float64_t CMultiLaplaceInferenceMethod::get_derivative_helper(SGMatrix<float64_t { result+=((eigen_E.block(0,bl*n,n,n)-eigen_U.block(0,bl*n,n,n).transpose()*eigen_U.block(0,bl*n,n,n)).array() *eigen_dK.array()).sum(); -		result-=(eigen_dK*eigen_alpha.block(bl*n,0,n,1)).dot(eigen_alpha.block(bl*n,0,n,1)); +		result-=(eigen_dK*eigen_alpha.segment(bl*n,n)).dot(eigen_alpha.segment(bl*n,n)); } return result/2.0; @@ -489,7 +489,7 @@ SGVector<float64_t> CMultiLaplaceInferenceMethod::get_derivative_wrt_mean( result[i]=0; //currently only compute the explicit term for(index_t bl=0; bl<C; bl++) -			result[i]-=eigen_alpha.block(bl*n,0,n,1).dot(eigen_dmu); +			result[i]-=eigen_alpha.segment(bl*n,n).dot(eigen_dmu); } return result; </ins>

shogun fails to build since the eigen 3.4.0 bump: The package is a likely candidate for removal. Upstream is unresponsive and development has halted. Removed from debian: Removed from fedora: Blocking vcpkg update: Please run and paste the result. Maintainer information:
I think you were the last one to modify this package, so please speak up if you need it. Also pinging Last call - if no one responds within the next week, I'll open a PR to remove this package.
Yes, I was working on making it build on Darwin and adding it as a Python 3 module. Well, I did, but I didn't feel motivated to create a PR. As you comment, upstream has been inactive for almost a year, the latest release is several years old, and it becomes harder and harder to make it work, and the patches would start to accumulate. To make it work on Darwin we need two upstream patches that fix the build with newer compiler versions. In the current derivation, the Python interface is not built because the CMake flag is not the right one. When enabled, Swig 3 is used to generate the Python interface, but Swig 3 doesn't support Python 3.8+ (and with Swig 4 just fails). It can be fixed with a patch, that feels more like a hack, intercepting the Makefile build, so I am not happy with it: Another small patch is needed to fix the deprecated . Also, I wasn't happy that adding it as a Python module will recompile the entire library again, which takes too much time IMO. I haven't checked if it is possible to build with Eigen 3.4 because it takes forever to compile. It could probably work on the development version. Note that the development version doesn't support Eigen 3.4 because of this, but it may work: But there is no such limitation on the 6.1.4 release, which probably means it would require another patch to fix the code, if somebody figures out. So, I'd argue that the package is too old now, and the derivation has too many issues, and it's too much of a hassle to maintain it, so it's probably better to just remove it.
I decided to sit and take a look at the error, and I actually fixed it.


Question: <ins> From: Sebastián Mancilla <smancill@smancill.dev> Subject: [PATCH] Fix compile errors when using Eigen 3.4 --- .../machine/gp/MultiLaplaceInferenceMethod.cpp | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/src/shogun/machine/gp/MultiLaplaceInferenceMethod.cpp b/src/shogun/machine/gp/MultiLaplaceInferenceMethod.cpp index 2e27678d2..60050afea 100644 --- a/src/shogun/machine/gp/MultiLaplaceInferenceMethod.cpp +++ b/src/shogun/machine/gp/MultiLaplaceInferenceMethod.cpp @@ -84,9 +84,9 @@ class CMultiPsiLine : public func_base float64_t result=0; for(index_t bl=0; bl<C; bl++) { -			eigen_f.block(bl*n,0,n,1)=K*alpha->block(bl*n,0,n,1)*CMath::exp(log_scale*2.0); -			result+=alpha->block(bl*n,0,n,1).dot(eigen_f.block(bl*n,0,n,1))/2.0; -			eigen_f.block(bl*n,0,n,1)+=eigen_m; +			eigen_f.segment(bl*n,n)=K*alpha->segment(bl*n,n)*CMath::exp(log_scale*2.0); +			result+=alpha->segment(bl*n,n).dot(eigen_f.segment(bl*n,n))/2.0; +			eigen_f.segment(bl*n,n)+=eigen_m; } // get first and second derivatives of log likelihood @@ -272,7 +272,7 @@ void CMultiLaplaceInferenceMethod::update_alpha() { Map<VectorXd> alpha(m_alpha.vector, m_alpha.vlen); for(index_t bl=0; bl<C; bl++) -			eigen_mu.block(bl*n,0,n,1)=eigen_ktrtr*CMath::exp(m_log_scale*2.0)*alpha.block(bl*n,0,n,1); +			eigen_mu.segment(bl*n,n)=eigen_ktrtr*CMath::exp(m_log_scale*2.0)*alpha.segment(bl*n,n); //alpha'*(f-m)/2.0 Psi_New=alpha.dot(eigen_mu)/2.0; @@ -316,7 +316,7 @@ void CMultiLaplaceInferenceMethod::update_alpha() for(index_t bl=0; bl<C; bl++) { -			VectorXd eigen_sD=eigen_dpi.block(bl*n,0,n,1).cwiseSqrt(); +			VectorXd eigen_sD=eigen_dpi.segment(bl*n,n).cwiseSqrt(); LLT<MatrixXd> chol_tmp((eigen_sD*eigen_sD.transpose()).cwiseProduct(eigen_ktrtr*CMath::exp(m_log_scale*2.0))+ MatrixXd::Identity(m_ktrtr.num_rows, m_ktrtr.num_cols)); MatrixXd eigen_L_tmp=chol_tmp.matrixU(); @@ -341,11 +341,11 @@ void CMultiLaplaceInferenceMethod::update_alpha() VectorXd tmp2=m_tmp.array().rowwise().sum(); for(index_t bl=0; bl<C; bl++) -			eigen_b.block(bl*n,0,n,1)+=eigen_dpi.block(bl*n,0,n,1).cwiseProduct(eigen_mu.block(bl*n,0,n,1)-eigen_mean_bl-tmp2); +			eigen_b.segment(bl*n,n)+=eigen_dpi.segment(bl*n,n).cwiseProduct(eigen_mu.segment(bl*n,n)-eigen_mean_bl-tmp2); Map<VectorXd> &eigen_c=eigen_W; for(index_t bl=0; bl<C; bl++) -			eigen_c.block(bl*n,0,n,1)=eigen_E.block(0,bl*n,n,n)*(eigen_ktrtr*CMath::exp(m_log_scale*2.0)*eigen_b.block(bl*n,0,n,1)); +			eigen_c.segment(bl*n,n)=eigen_E.block(0,bl*n,n,n)*(eigen_ktrtr*CMath::exp(m_log_scale*2.0)*eigen_b.segment(bl*n,n)); Map<MatrixXd> c_tmp(eigen_c.data(),n,C); @@ -409,7 +409,7 @@ float64_t CMultiLaplaceInferenceMethod::get_derivative_helper(SGMatrix<float64_t { result+=((eigen_E.block(0,bl*n,n,n)-eigen_U.block(0,bl*n,n,n).transpose()*eigen_U.block(0,bl*n,n,n)).array() *eigen_dK.array()).sum(); -		result-=(eigen_dK*eigen_alpha.block(bl*n,0,n,1)).dot(eigen_alpha.block(bl*n,0,n,1)); +		result-=(eigen_dK*eigen_alpha.segment(bl*n,n)).dot(eigen_alpha.segment(bl*n,n)); } return result/2.0; @@ -489,7 +489,7 @@ SGVector<float64_t> CMultiLaplaceInferenceMethod::get_derivative_wrt_mean( result[i]=0; //currently only compute the explicit term for(index_t bl=0; bl<C; bl++) -			result[i]-=eigen_alpha.block(bl*n,0,n,1).dot(eigen_dmu); +			result[i]-=eigen_alpha.segment(bl*n,n).dot(eigen_dmu); } return result; </ins>

I don't really use Eigen but the patch makes sense. So, I can send a PR to keep this package on the repo for another cycle at least. I mean, I already did all of the work and it builds. Other distros end up removing it because nobody cares to maintain it.
Nice! Thanks for looking into it. Like you said, if you've already done the work to get it working I don't see why not. If it's too much work to keep it working in the future we can always revisit this and drop it.


Question: ''; in runCommand name { <del> meta = importMeta; passthru.env = runCommand "${name}-shell-env" { </del> <ins> inherit meta; passthru = passthru // { env = runCommand "${name}-shell-env" { </ins> shellHook = '' export CHROOTENV_EXTRA_BINDS="${lib.concatStringsSep ":" extraBindMounts}:$CHROOTENV_EXTRA_BINDS" exec ${chroot-user}/bin/chroot-user ${env} bash -l ${init "bash"} "$(pwd)"

This weekend I tried these games, all deadlocked in the menu or character selection. Nyheim Oh...Sir! The Insult Simulator Reigns Unturned (free to play) You don't have to be worried to waste money in case you want to test a game. I have had no problem when requesting refunds, just go to I have played these games and found no issues with them: Dota 2 Counter-Strike TIS-100 World of goo Faster Than Light You Must Build a Boat Risk of Rain System: (NixOS: , Ubuntu/Fedora: , ...) 03pre99759. (Gorilla) Nix version: (run ) nix-env (Nix) 1.11.6 Nixpkgs version: (run ) "17.03pre99759." Integrated graphics card, 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
This is normal with steam on nixos unfortunately. There are many steam games that don't work for various reasons, unfortunately many linux steam game developers only make sure their games run on ubuntu and don't really care about relying only on dependencies from the steam runtime. Some games don't play nice with certain graphics cards or drivers as well. If you want to get a particular game working (I can list 150 games that work under nixos with nvidia card and drivers at least) then you'll need to do some work, or at least post any relevant logs from the game/steam so people can actually help you solve the problem. That is assuming that they own the game. :)
There's a slowly-growing list of extra dependencies in the Steam package. If you can figure out what's missing, you can add it there; e.g. as in
I don't have enough motivation to actually buy games for the sole purpose of fixing them and then refunding, sorry. Nevertheless, I'm happy to help if you can post logs and/or s -- those two are the most helpful for determining FHS-related problems.


Question: systemd.services.rpcbind = { wantedBy = [ "multi-user.target" ]; <ins> # rpcbind performs a check for /var/run/rpcbind.lock at startup # and will crash if /var/run isn't present. In the stock NixOS # var.conf tmpfiles configuration file, /var/run is symlinked to # /run, so rpcbind can enter a race condition in which /var/run # isn't symlinked yet but tries to interact with the path, so # controlling the order explicitly here ensures that rpcbind can # start successfully. The `wants` instead of `requires` should # avoid creating a strict/brittle dependency. wants = [ "systemd-tmpfiles-setup.service" ]; after = [ "systemd-tmpfiles-setup.service" ]; </ins> }; users.users.rpc = {

In NixOS VM tests, service sometimes fails to start. This breaks e.g. GlusterFS tests. Steps to reproduce the behavior: Building — GlusterFS service fails due to dependency on RPC Bind service. See also Some result related to GlusterFS. Have not yet had time to bisect and determine what's going on.
Hey, I started down this path looking for an updated Glusterfs package, then found the paused PR, which linked here. Fortunately, I think I know the root cause. As you noted, the failure is due to a dependency failure on - the error message in journald is: This was sort of confusing, but I found that led me to . The NixOS config includes: L /var/run - - - - ../run So my suspicion is that starts before and can't check for the lockfile. Since there's no unit, which was my first guess, I've instead been adding and tied to , which makes the tests pass. The diff that makes this work is: Obviously we should probably make this fix in NixOS proper, but I want to double-check with you that such a wider-impact change is safe to make. The proposed global_ fix for NixOS would be: thoughts/feedback? I can PR the fix if this all sounds right.
The real problem is that I am competent about neither rpcbind nor systemd-tmpfiles (otherwise I would try to write a more sensible complaint). Maybe PR the change (if it indeed fixes rpcbind judging from logs + fixes GlusterFS tests + doesn't break any NixOS tests that passed right before) and see if more competent people show up? It does feel to me that ideally tmpfiles should not depend on rpcbind and if they do (dunno, because we have /tmp on GlusterFS???) we are doomed anyway…
You and I are in the same boat, friend :joy: I'm only rpcbind-aware as it applies to GlusterFS, so I don't count myself as an expert, either. The only reason I feel confident enough to PR a fix is that all the pieces line up here and the passing tests make me think that this does indeed strike at the root cause.


Question: systemd.services.rpcbind = { wantedBy = [ "multi-user.target" ]; <ins> # rpcbind performs a check for /var/run/rpcbind.lock at startup # and will crash if /var/run isn't present. In the stock NixOS # var.conf tmpfiles configuration file, /var/run is symlinked to # /run, so rpcbind can enter a race condition in which /var/run # isn't symlinked yet but tries to interact with the path, so # controlling the order explicitly here ensures that rpcbind can # start successfully. The `wants` instead of `requires` should # avoid creating a strict/brittle dependency. wants = [ "systemd-tmpfiles-setup.service" ]; after = [ "systemd-tmpfiles-setup.service" ]; </ins> }; users.users.rpc = {

If NixOS is shipping with that tmpfiles configuration to bootstrap , then I think it makes sense for the downstream NixOS module to accomodate how NixOS is handling . So my initial instinct of patching upstream probably doesn't apply since distros are probably handling differently. I'll PR the change and we can see about additional feedback for us.
I'm feeling pretty confident that fixed the rpcbind problem - are there any nixosTests that should be re-enabled now that rpcbind reliably runs? I looked around for disabled tests but am not sure where those might live, if any are still disabled. Otherwise, I think we can close this :crossed_fingers:
(looked at the tests, doesn't look like there is a ton of disabled ones)


Question: diff -ru old/webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp --- old/webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp	2019-09-09 04:47:07.000000000 -0400 +++ webkitgtk-2.26.0/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp	2019-09-20 21:14:10.537921173 -0400 <del> @@ -585,7 +585,7 @@ { SCMP_SYS(keyctl), nullptr }, { SCMP_SYS(request_key), nullptr }, -        // Scary VM/NUMA ops +        // Scary VM/NUMA ops { SCMP_SYS(move_pages), nullptr }, { SCMP_SYS(mbind), nullptr }, { SCMP_SYS(get_mempolicy), nullptr }, @@ -724,6 +724,11 @@ </del> <ins> @@ -724,6 +724,12 @@ </ins> "--ro-bind-try", "/usr/local/lib64", "/usr/local/lib64", "--ro-bind-try", PKGLIBEXECDIR, PKGLIBEXECDIR,

Describe the bug Epiphany crashes on startup with a bind mount error. To Reproduce Steps to reproduce the behavior: epiphany Expected behavior The browser should startup Additional context Error: exists and opengl is enabled I bet is relevant Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Maintainer information:
I can't reproduce this on my machine. Can you try running it with ?
Thanks for responding. I think this is the relevant part from :
Ah, this only shows that emits the error message. To trace what it actually does, could you try adding the flag?
I just piped it all into here:
The output got cut off there, unfortunately. Maybe you could just attach the text file directly to your reply?
Sorry about that, here is the file:
Thanks for the log! I think I've found the culprit. I've opened which seems to fix it - please try it out.


Question: }) ]; <del> vendorHash = "sha256-NtNjH2Vo1Leh98VIOkpyALErhC+6H5BE/uaPkwlejoo="; </del> <ins> vendorHash = "sha256-M5e5dE1gGW3ly94r3SxCsBmVwbBmhVtaVDW691vxG/8="; </ins> nativeBuildInputs = lib.optionals stdenv.isLinux [ makeWrapper ] ++ [ installShellFiles ];

Package name: tailscale Latest released version: 1.72.0 <!-- Search your package here: --- Current version on the unstable channel: 1.70.0 Current version on the stable/release channel: 1.66.4 <!-- 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]:


Question: } } diff --git a/services/FilesService.php b/services/FilesService.php <del> index 7d070350..fba2e923 100644 </del> <ins> index 7d070350..a6dd4b08 100644 </ins> --- a/services/FilesService.php +++ b/services/FilesService.php <del> @@ -103,7 +103,7 @@ class FilesService extends BaseService </del> <ins> @@ -10,7 +10,7 @@ class FilesService extends BaseService </ins> <del> public function GetFilePath($group, $fileName) </del> <ins> public function __construct() </ins> { <del> -		$groupFolderPath = $this->StoragePath . '/' . $group; </del> <ins> -		$this->StoragePath = GROCY_DATAPATH . '/storage'; </ins> +		$this->StoragePath = getenv('GROCY_STORAGE_DIR'); <del> if (!file_exists($groupFolderPath)) </del> <ins> if (!file_exists($this->StoragePath)) </ins> { <ins> mkdir($this->StoragePath); </ins> diff --git a/services/StockService.php b/services/StockService.php <del> index f73ac5bd..6b6e693a 100644 </del> <ins> index 85f57803..15556112 100644 </ins> --- a/services/StockService.php +++ b/services/StockService.php <del> @@ -1589,8 +1589,7 @@ class StockService extends BaseService </del> <ins> @@ -1704,8 +1704,7 @@ class StockService extends BaseService </ins> throw new Exception('No barcode lookup plugin defined'); }

Grocy does not properly save manuals for equipment The issue appears to be introduced by in a patch applied by nixpkgs. Changing that hunk to: Fixes the issue. I'm not currently setup for making a PR, I'm a bit busy, but I wanted an issue for other people to find if they run into the problem. grocy in nixos configuration (admin/admin is default) a new piece of equipment and attach a PDF manual to it to download manual; it will fail system: host os: multi-user?: sandbox: version: channels(aidenn): channels(root): nixpkgs:
appears to be the maintainer.
I marked this as stale due to inactivity. →


Question: libcardiacarrest = callPackage ../misc/libcardiacarrest { }; <del> easyeffects = callPackage ../applications/audio/easyeffects { }; </del> <ins> easyeffects = callPackage ../applications/audio/easyeffects { # Fix crashes with speexdsp effects speexdsp = speexdsp.override { withFftw3 = false; }; }; </ins> pulseeffects-legacy = callPackage ../applications/audio/pulseeffects-legacy { };

Easyeffects crashes when Echo Canceller is used (at least when applied on input). I've been told that it works fine on arch linux. Though it might be my hardware that somehow makes it crash. Steps to reproduce the behavior: Echo Canceller module to the Input Easy Effects to one of recording apps It doesn't crash It doesn't write anything useful in the logs, just exits with code 137. Please run and paste the result.
I can reproduce it but it is not a regular crash – there is not core dump. It appears to be killed. Weirdly when I run it with: The termination is not caught.
For me it reproduced with gdb: Maybe it's terminated when child process is crashed?
hmm, it seems to be something wrong with speex when configured to use the fftw library... not sure what, but this doesn't crash:
The same also happens in Speech Processor effect now:
Unfortunately this didn't seem to do the trick for me, it still crashes with the Echo Canceller.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I have the same problem. The thing is, used to work OK on my system. Then I tried the module, after which this issue appeared. However, now it's persisting. I undid the change, even tried booting into old generation, but is still getting killed with the echo canceller on. For reference, this is what I used to try to enable the echo cancel module (not sure if it ever worked):


Question: <ins> diff --git a/catboost/python-package/setup.py b/catboost/python-package/setup.py index 17f1d8ff14..07da618cd1 100644 --- a/catboost/python-package/setup.py +++ b/catboost/python-package/setup.py @@ -80,7 +80,7 @@ class Helper(object): self.with_cuda = os.environ.get('CUDA_PATH') or os.environ.get('CUDA_ROOT') or None self.os_sdk = 'local' self.with_ymake = True -        self.parallel = None +        self.parallel = os.environ.get('NIX_BUILD_CORES') or None def finalize_options(self): if os.path.exists(str(self.with_cuda)): @@ -222,11 +222,12 @@ class build_ext(_build_ext): def build_with_make(self, topsrc_dir, build_dir, catboost_ext, put_dir, verbose, dry_run): logging.info('Buildling {} with gnu make'.format(catboost_ext)) -        makefile = 'python{}.{}CLANG50-LINUX-X86_64.makefile'.format(python_version()[0], 'CUDA.' if self.with_cuda else '') +        makefile = 'python{}.{}CLANG7-LINUX-X86_64.makefile'.format(python_version()[0], 'CUDA.' if self.with_cuda else '') make_cmd = [ 'make', '-f', '../../make/' + makefile, -            'CC=clang-5.0', -            'CXX=clang++-5.0', +            'CC=clang', +            'CXX=clang++', +            'PYTHON=python2', 'BUILD_ROOT=' + build_dir, 'SOURCE_ROOT=' + topsrc_dir, ] diff --git a/make/python2.CLANG7-LINUX-X86_64.makefile b/make/python2.CLANG7-LINUX-X86_64.makefile index e54b7078e8..fb7b208af9 100644 --- a/make/python2.CLANG7-LINUX-X86_64.makefile +++ b/make/python2.CLANG7-LINUX-X86_64.makefile @@ -4,33 +4,6 @@ BUILD_ROOT = $(shell pwd) SOURCE_ROOT = $(shell pwd) PYTHON = $(shell which python) -ifneq ($(MAKECMDGOALS),help) -define _CC_TEST -__clang_major__ __clang_minor__ -endef - -_CC_VERSION = $(shell echo '$(_CC_TEST)' | $(CC) -E -P -) -$(info _CC_VERSION = '$(_CC_VERSION)') - -ifneq '$(_CC_VERSION)' '7 0' -    $(error clang 7.0 is required) -endif -endif - -ifneq ($(MAKECMDGOALS),help) -define _CXX_TEST -__clang_major__ __clang_minor__ -endef - -_CXX_VERSION = $(shell echo '$(_CXX_TEST)' | $(CXX) -E -P -) -$(info _CXX_VERSION = '$(_CXX_VERSION)') - -ifneq '$(_CXX_VERSION)' '7 0' -    $(error clang 7.0 is required) -endif -endif - - all :: $(BUILD_ROOT)/catboost/python-package/catboost/_catboost.so diff --git a/make/python2.CUDA.CLANG7-LINUX-X86_64.makefile b/make/python2.CUDA.CLANG7-LINUX-X86_64.makefile index 2a22a79b25..522fb54a7c 100644 --- a/make/python2.CUDA.CLANG7-LINUX-X86_64.makefile +++ b/make/python2.CUDA.CLANG7-LINUX-X86_64.makefile @@ -4,33 +4,6 @@ BUILD_ROOT = $(shell pwd) SOURCE_ROOT = $(shell pwd) PYTHON = $(shell which python) -ifneq ($(MAKECMDGOALS),help) -define _CC_TEST -__clang_major__ __clang_minor__ -endef - -_CC_VERSION = $(shell echo '$(_CC_TEST)' | $(CC) -E -P -) -$(info _CC_VERSION = '$(_CC_VERSION)') - -ifneq '$(_CC_VERSION)' '7 0' -    $(error clang 7.0 is required) -endif -endif - -ifneq ($(MAKECMDGOALS),help) -define _CXX_TEST -__clang_major__ __clang_minor__ -endef - -_CXX_VERSION = $(shell echo '$(_CXX_TEST)' | $(CXX) -E -P -) -$(info _CXX_VERSION = '$(_CXX_VERSION)') - -ifneq '$(_CXX_VERSION)' '7 0' -    $(error clang 7.0 is required) -endif -endif - - all :: $(BUILD_ROOT)/catboost/python-package/catboost/_catboost.so diff --git a/make/python3.CLANG7-LINUX-X86_64.makefile b/make/python3.CLANG7-LINUX-X86_64.makefile index fee6750bcb..dc55908371 100644 --- a/make/python3.CLANG7-LINUX-X86_64.makefile +++ b/make/python3.CLANG7-LINUX-X86_64.makefile @@ -4,33 +4,6 @@ BUILD_ROOT = $(shell pwd) SOURCE_ROOT = $(shell pwd) PYTHON = $(shell which python) -ifneq ($(MAKECMDGOALS),help) -define _CC_TEST -__clang_major__ __clang_minor__ -endef - -_CC_VERSION = $(shell echo '$(_CC_TEST)' | $(CC) -E -P -) -$(info _CC_VERSION = '$(_CC_VERSION)') - -ifneq '$(_CC_VERSION)' '7 0' -    $(error clang 7.0 is required) -endif -endif - -ifneq ($(MAKECMDGOALS),help) -define _CXX_TEST -__clang_major__ __clang_minor__ -endef - -_CXX_VERSION = $(shell echo '$(_CXX_TEST)' | $(CXX) -E -P -) -$(info _CXX_VERSION = '$(_CXX_VERSION)') - -ifneq '$(_CXX_VERSION)' '7 0' -    $(error clang 7.0 is required) -endif -endif - - all :: $(BUILD_ROOT)/catboost/python-package/catboost/_catboost.so diff --git a/make/python3.CUDA.CLANG7-LINUX-X86_64.makefile b/make/python3.CUDA.CLANG7-LINUX-X86_64.makefile index 5146830476..ff8535b03e 100644 --- a/make/python3.CUDA.CLANG7-LINUX-X86_64.makefile +++ b/make/python3.CUDA.CLANG7-LINUX-X86_64.makefile @@ -4,33 +4,6 @@ BUILD_ROOT = $(shell pwd) SOURCE_ROOT = $(shell pwd) PYTHON = $(shell which python) -ifneq ($(MAKECMDGOALS),help) -define _CC_TEST -__clang_major__ __clang_minor__ -endef - -_CC_VERSION = $(shell echo '$(_CC_TEST)' | $(CC) -E -P -) -$(info _CC_VERSION = '$(_CC_VERSION)') - -ifneq '$(_CC_VERSION)' '7 0' -    $(error clang 7.0 is required) -endif -endif - -ifneq ($(MAKECMDGOALS),help) -define _CXX_TEST -__clang_major__ __clang_minor__ -endef - -_CXX_VERSION = $(shell echo '$(_CXX_TEST)' | $(CXX) -E -P -) -$(info _CXX_VERSION = '$(_CXX_VERSION)') - -ifneq '$(_CXX_VERSION)' '7 0' -    $(error clang 7.0 is required) -endif -endif - - all :: $(BUILD_ROOT)/catboost/python-package/catboost/_catboost.so </ins>

Would be a very useful package to have for ML Enthusiasts Project description Machine Learning Catboost Library Metadata CatBoost is a high-performance open source library for gradient boosting on decision trees homepage URL: source URL: license: Apache License 2.0 platforms: Linux installation instructions: Please let me know if I should stop tagging you in random issues and it bothers you (sorry, i'll stop), but I thought this might be of interest to you since you are very involved in tensorflow.
taggining maintainers of xgboost and lightgbm. Wondering if you could look into compiling catboost too?
I use tensorflow at work, which is why I care :). But I'm not a data-scientist
understood, thank you. GPU support for catboost would also be very welcome.
Looks like they have a non standard install script. But definitely doable. Sadly I don't think I have time in the near future but would be happy to point you in the right direction to get stared with a PR
both eyes wide open - i'll try to start this w/e, any pointers very welcome, thank you.
Currently failing to build on nix, although the file clearly exists.
- maybe it's easier if you create a work-in-progress pull request so other people can check? Two things that stand out are: looks like something is being downloaded during the build process. This won't work with sandboxing because there won't be a working network. builds should be isolated, i.e. access to should be rewritten to the local build directory, not (probably hardcoded somewhere in the build scripts). Packaging for nix can be quite fiddly - I think might be a good example for fetching complex dependencies + build script patches.
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 .


Question: gcc-armhf-embedded = pkgsCross.armhf-embedded.buildPackages.gcc; }; <del> tdm = callPackage ../games/tdm { }; </del> newlib = callPackage ../development/misc/newlib { }; newlibCross = callPackage ../development/misc/newlib { stdenv = crossLibcStdenv;

Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: tdmupdater tdm Expected behavior tdm starts. Actual behaviour tdm starts with a black error and has stderr errors such as: Additional context It looks like the problem might be that and the assets downloaded via tdmupdater are different versions: Workaround (Steam isn't actually used for this. This is just a lazy way to run FHS programs.) Notify maintainers Metadata** Maintainer information:
There's a version update in master. I don't know when it'll land in unstable (maybe it already did?) or stable.
Is it possible to have NixOS stable not break when upstream changes? Either: (a) NixOS stable should include the TDM assets (in which case tdm_update is not needed) (b) becomes solely a shim to grab assets from the TDM assets, so it doesn't matter which version of is used.
require patching the path to ELF interpreter, along with worrying about lib dependencies. complicated: TDM players are accustomed to dowloading extra missions, which requires a writable directory to hold the data. Do you have a proposal how to do this securely? Hardlinking the default install to /home would break if /home is on a different FS. Suid wrappers smell. World-writable bits in /nix smell too.
Surely the engine supports multiple asset directories, so we can load the assets from the nix store in addition to whatever was installed manually into a local directory.
The comments on suggest The Dark Mod stores save games in its installation directory. tracks this issue.
I have another issue that seem to be related. Running tdm via the ` work however. The relevent line are: When it doesn't work and with the second option
I poked around - and I don't have any ideas why OpenAL might not be finding hardware. Right now, it seems that the best course of action is to remove TDM from repos (to avoid creating false expectations), and run it with steam-run. and do you agree?


Question: <ins> #include <cxxabi.h> #include <iostream> int main(int argc, char **argv) { std::cerr << "ok" << std::endl; return 0; } </ins>

Clang's wrapper does not set as an include path. Compiling files with since <cxxabi.hrequires is present in the aforementioned path I created the environment using this minimal mkShell expression Adding to
Proposed solution seems reasonable to me. See also started by
Please can you also include the nixpkgs commit hash in the repro (sorry if it's there and I missed it).
Oh thank you, that makes so much sense, I was also looking at how the monorepo handles things as well as their tests on finding the system include headers and what you said is probably the correct reason. Ah, it was the nixpkgs-unstable revision updated just then. Sorry I do not have that, but you can reproduce it with the current master as well.


Question: { lib, stdenv, fetchurl , meson, ninja, pkg-config, python3, wayland-scanner , cairo, colord, dbus, lcms2, libGL, libXcursor, libdrm, libevdev, libinput <del> , libjpeg, libseat, libxcb, libxkbcommon, mesa, mtdev, pam, udev, wayland </del> <ins> , libjpeg, seatd, libxcb, libxkbcommon, mesa, mtdev, pam, udev, wayland </ins> , wayland-protocols, xlibsWrapper , pipewire ? null, pango ? null, libunwind ? null, freerdp ? null, vaapi ? null , libva ? null, libwebp ? null, xwayland ? null

error while building using unstable channel trying to build a system using weston pkg building successfully I assume its an easy name swap changing "libseat" on 4th line to "seatd"


Question: hash = "sha256-WtTVSWWSlfXrdPVsnlDe4P5K/Fnj4QsOzx3Wo/Kusmg="; includes = [ "src/gui/meson.build" ]; }) <ins> ] # Pagesize detection via syscall; remove when next stable version arrives ++ [ (fetchpatch { # Added as a parent commit of 7e20f6e # Fix ppc64le backend and 64K page size support (#2828) name = "meson-add-ppc64.patch"; url = "https://github.com/dosbox-staging/dosbox-staging/commit/765bcc2b1d87050a4ea366bf22e1db075ad5660b.patch"; hash = "sha256-RtkidyF7w6RrPmCKK4Bd+3FtAn/+/38xk2cl32+yzxw="; includes = [ "meson.build" ]; }) (fetchpatch { # Added as a parent commit of 7e20f6e # Account for debian powerpc prefix (instead of ppc) name = "meson-powerpc64le.patch"; url = "https://github.com/dosbox-staging/dosbox-staging/commit/d44aa7441cd871ffac08974f22af7a735a839288.patch"; hash = "sha256-oMZtfmB1CRlDWyXwEWc3XzC+XxKazXDgo+jUiNBoJDw="; includes = [ "meson.build" ]; }) (fetchpatch { # Added as a parent commit of 7e20f6e # Restore the PowerPC dynrec core to working order name = "meson-option-write-or-execute.patch"; url = "https://github.com/dosbox-staging/dosbox-staging/commit/ef86642de390839afc77b2b591a6ea9ac43909b3.patch"; hash = "sha256-htOKEaXRRy28XNMX/t6uFTBLCkTr7YPtfmI9UyIBiz4="; includes = [ "meson_options.txt" ]; }) (fetchpatch { # Use a system call to detect the page size name = "meson-detect-pagesize-by-syscall.patch"; url = "https://github.com/dosbox-staging/dosbox-staging/commit/7e20f6e401956a7a308f1b3462294d7ac9fa5db8.patch"; hash = "sha256-QW9lpHWCYSlQFgTqX/UxHAAWisz4wfPrdjLqROn/wR0="; }) </ins> ]; nativeBuildInputs = [

Steps to reproduce the behavior: dosbox-staging on darwin Complaining that alsa-lib not available on darwin I suggest referencing the derivation of in which use to opt-in dependencies P.S. wonder why the maintenance of this package is separated from and Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't have a Darwin machine. Nice. A full log would be nicer of course, but nice nonetheless. Wonder why they should be maintained by the same people.


Question: <del> { lib , stdenv , fetchurl , acl , attr , bzip2 , libcdio , libiconv , readline , zlib }: stdenv.mkDerivation (finalAttrs: { pname = "xorriso"; version = "1.5.7-unstable-2023-12-06"; src = fetchurl { url = "https://web.archive.org/web/20231206123448/https://www.gnu.org/software/xorriso/xorriso-1.5.7.tar.gz"; hash = "sha256-B7lV3n3e1aF7yJsLxwi8C8m3sBmUUePpCV9KfWRuTm0="; }; buildInputs = [ bzip2 libcdio libiconv readline zlib ] ++ lib.optionals stdenv.isLinux [ acl attr ]; outputs = [ "out" "man" ]; env.NIX_CFLAGS_COMPILE = lib.optionalString stdenv.isDarwin "-include unistd.h"; doCheck = true; strictDeps = true; meta = { homepage = "https://www.gnu.org/software/xorriso/"; description = "ISO 9660 Rock Ridge file system manipulator"; longDescription = '' GNU xorriso copies file objects from POSIX compliant filesystems into Rock Ridge enhanced ISO 9660 filesystems and allows session-wise manipulation of such filesystems. It can load the management information of existing ISO images and it writes the session results to optical media or to filesystem objects. Vice versa xorriso is able to copy file objects out of ISO 9660 filesystems. ''; license = lib.licenses.gpl3Plus; mainProgram = "xorriso"; maintainers = [ lib.maintainers.AndersonTorres ]; platforms = lib.platforms.unix; }; }) </del>

Can't build xorriso due to source archive hash mismatch. Steps to reproduce the behavior: the substituter -shell -p xorriso nixpkgs 23.11.5408.
Probably it comes from a moving target... Let's go!
How exactly it happened? Here is the url: Is web archive failing?? P.S.: since Xorriso is just another name for libisoburn, I will remove xorriso and link-alias it to libisoburn.


Question: <ins> { config, pkgs, lib, ... }: let cfg = config.services.turn-rs; format = pkgs.formats.toml { }; in { options.services.turn-rs = { enable = lib.mkEnableOption "turn-rs server"; package = lib.mkPackageOption pkgs "turn-rs" { }; secretFile = lib.mkOption { type = lib.types.nullOr lib.types.path; default = null; example = "/run/keys/turn-rs.env"; description = '' Environment variables from this file will be interpolated into the final config file using envsubst with this syntax: `$ENVIRONMENT` or `''${VARIABLE}`. The file should contain lines formatted as `SECRET_VAR=SECRET_VALUE`. This is useful to avoid putting secrets into the nix store. ''; }; settings = lib.mkOption { type = lib.types.submodule { freeformType = format.type; }; description = "Turn-rs server config file"; default = { }; example = { turn = { realm = "localhost"; interfaces = [ { transport = "udp"; bind = "127.0.0.1:3478"; external = "127.0.0.1:3478"; } { transport = "tcp"; bind = "127.0.0.1:3478"; external = "127.0.0.1:3478"; } ]; }; auth.static_credentials = { user1 = "test"; user2 = "test"; }; }; }; }; config = lib.mkIf cfg.enable { services.turn-rs.settings = { api.bind = lib.mkDefault "127.0.0.1:3000"; log.level = lib.mkDefault "info"; }; systemd.services.turn-rs = { enable = true; wantedBy = [ "multi-user.target" ]; description = "Turn-rs Server Daemon"; preStart = let configFile = format.generate "turn-rs-config.toml" cfg.settings; in '' ${lib.getExe pkgs.envsubst} -i "${configFile}" -o /run/turn-rs/config.toml ''; serviceConfig = { RuntimeDirectory = "turn-rs"; EnvironmentFile = lib.optional (cfg.secretFile != null) cfg.secretFile; ExecStart = "${lib.getExe cfg.package} --config=/run/turn-rs/config.toml"; DynamicUser = true; }; }; }; } </ins>

Project description A pure rust implemented turn server. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: gpl-3.0 platforms: linux, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: tracker = callPackage ../development/libraries/tracker { }; <del> tracker-miners = callPackage ../development/libraries/tracker-miners { }; </del> tracy = callPackage ../development/tools/tracy { }; trivy = callPackage ../tools/admin/trivy { };

Package name: tracker-miners Latest released version: 3.7.3 <!-- Search your package here: --- Current version on the unstable channel: 3.7.2 Current version on the stable/release channel: 3.6.2 <!-- 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. -- Tracker was updated in , however tracker-miners wasn't. It currently suffers from this bug: (and generates a lot of failures on a running gnome system). It was fixed in 3.7.3. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
PRs are welcomed.


Question: <ins> #! /usr/bin/env nix-shell #! nix-shell -i bash -p curl go-pup # Fetches a list of all available source mirrors from the sage homepage. # Note that the list is sorted by country, but fetchurl doesn't offer an option # to customize mirror preference. curl -s http://www.sagemath.org/download-source.html  | pup 'table#mirror'   | pup 'a attr{href}'  | sed -e 's/index.html/sage-${version}.tar.gz/' </ins>

Since Sage is huge and complicated, I figured I would make this issue to collaboratively track progress and share branches. One big issue is that Sage 7 , instead they use some with scant documentation . has the correct SHA256 for Sage 7.6 and updates a patch file. It currently fails when Sage tries to build . Some nice things to do for the future: ) cc:
thanks for picking this up
Me myself being a miserable loser who has failed to update Sage in the past, I hope you succeed… My attempt hit the following wall. It is unbearably slow to let Sage build everything, but when I had convinced it to use the system versions of majority of dependencies it began to complain cryptically about their interaction in some case.
Can you elaborate? Do you have a branch that has that work? Also, to be clear: I probably don't have the skills or time to upgrade Sage by myself, I was hoping that if we shared our knowledge and de-duplicated efforts we might be able to get closer together
I think it was 6-dot-something; it required a metric ton of adding options to the packages in NixPkgs (I have pushed that all to master long ago), and the Sage tricks are most likely too version-specific. It was long enough ago that I have since abandoned and lost the changes.
In case anybody in here is still waiting for this: I got sage to compile and run. I'm currently trying to minimize the dependencies and check that everything is working correctly (there is one doctest failure, but it was mentioned multiple times in the mailing list and apperas to be harmles -- just a timeout). I'll probably make a PR in the next couple of days.


Question: <ins> #! /usr/bin/env nix-shell #! nix-shell -i bash -p curl go-pup # Fetches a list of all available source mirrors from the sage homepage. # Note that the list is sorted by country, but fetchurl doesn't offer an option # to customize mirror preference. curl -s http://www.sagemath.org/download-source.html  | pup 'table#mirror'   | pup 'a attr{href}'  | sed -e 's/index.html/sage-${version}.tar.gz/' </ins>

Sage needs texlive-core-2014, which is deprecated. Run with modern nixpkgs (i.e. from git) System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:


Question: procps-ng = callPackage ../os-specific/linux/procps-ng { }; <ins> watch = callPackage ../os-specific/linux/procps/watch.nix { }; </ins> qemu_kvm = lowPrio (qemu.override { x86Only = true; }); firmwareLinuxNonfree = callPackage ../os-specific/linux/firmware/firmware-linux-nonfree { };

Which version does it attempt to build? See for explanation.
9
Hmm, are you sure procps(-ng) can work on darwin? I found just
The only reason I wanted it was for the utility, which does work on Darwin. Homebrew has a separate installation target for , so maybe we can do that too.
I see, I noticed that. I'll leave it open then.
Since there is now a specific watch expression, this is no longer a bug.


Question: rustPlatform.buildRustPackage rec { pname = "atuin"; <del> version = "18.0.1"; </del> <ins> version = "18.0.2"; </ins> src = fetchFromGitHub { owner = "atuinsh"; repo = "atuin"; rev = "v${version}"; <del> hash = "sha256-fuVSn1vhKn2+Tw5f6zBYHFW3QSL4eisZ6d5pxsj5hh4="; </del> <ins> hash = "sha256-1ZNp6e2ZjVRU0w9m8YDWOHApu8vRYlcg6MJw03ZV49M="; </ins> }; <del> patches = [ # atuin with bash-preexec wasn't recording history properly after searching, # backport recent fix until next release (fetchpatch { url = "https://github.com/atuinsh/atuin/commit/cb11af25afddbad552d337a9c82e74ac4302feca.patch"; sha256 = "sha256-cG99aLKs5msatT7vXiX9Rn5xur2WUjQ/U33nOxuon7I="; }) ]; </del> # TODO: unify this to one hash because updater do not support this cargoHash = if stdenv.isLinux <del> then "sha256-lHWgsVnjSeBmd7O4Fn0pUtTn4XbkBOAouaRHRozil50=" else "sha256-LxfpllzvgUu7ZuD97n3W+el3bdOt5QGXzJbDQ0w8seo="; </del> <ins> then "sha256-1yGv6Tmp7QhxIu3GNyRzK1i9Ghcil30+e8gTvyeKiZs=" else "sha256-+QdtQuXTk7Aw7xwelVDp/0T7FAYOnhDqSjazGemzSLw="; </ins> # atuin's default features include 'check-updates', which do not make sense # for distribution builds. List all other default features.

Package name: atuin Latest released version: 18.0.1 Current version on the unstable channel: 18.0.1 Current version on the stable/release channel: 17.0.1 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
If you are planning to open a PR anyway, you don't need to open an issue.
Cool, thanks. I was unsure of the policy around that


Question: <ins> { lib, fetchFromGitHub, rustPlatform, installShellFiles }: rustPlatform.buildRustPackage rec { pname = "httm"; version = "0.9.0"; src = fetchFromGitHub { owner = "kimono-koans"; repo = pname; rev = version; sha256 = "sha256-uqzwS7+OQsPdMv3+fWdn3yVFJwtFZNd8kVWw//mQZj8="; }; cargoSha256 = "sha256-EC3E5NawsDe+CU5WEu0G3FWVLuqW5nXOoUURN0iDPK0="; nativeBuildInputs = [ installShellFiles ]; postInstall = '' installManPage httm.1 installShellCompletion --cmd httm  --zsh scripts/httm-key-bindings.zsh ''; meta = with lib; { description = "Interactive, file-level ZFS Time Machine-like tool"; homepage = "https://github.com/kimono-koans/httm"; license = licenses.mpl20; platforms = platforms.unix; maintainers = with maintainers; [ wyndon ]; }; } </ins>

Project description httm prints the size, date and corresponding locations of available unique versions (deduplicated by modify time and size) of files residing on ZFS snapshots, but can also be used interactively to view and restore such files. httm might change the way you use ZFS snapshots (because ZFS isn't designed for finding for unique file versions) or the Time Machine concept (because httm is very fast!). Metadata homepage URL: source URL: license: Mozilla Public License 2.0 platforms: unix, linux, darwin
Oh great thanks! Searched first but missed this.


Question: buildGoModule rec { pname = "ko"; <del> version = "0.15.2"; </del> <ins> version = "0.15.3"; </ins> src = fetchFromGitHub { owner = "ko-build"; repo = pname; rev = "refs/tags/v${version}"; <del> hash = "sha256-/1s335bXbBKlzKT4AevuHltLdU2qj6pJFngOrJCLtUw="; </del> <ins> hash = "sha256-H/S2TNzUIAjHDCrfQ3pkHC3yVf1k1DYkR5eBme8Cuq4="; </ins> }; <del> vendorHash = null; </del> <ins> vendorHash = "sha256-RrcJJzjmihjR/E19Pqgl//+yweRsaqWZ0yPcd1AvOc0="; </ins> nativeBuildInputs = [ installShellFiles ];

Package name: ko Latest released version: 0.15.3 <!-- Search your package here: --- Current version on the unstable channel: 0.15.2 Current version on the stable/release channel: 0.15.1 <!-- 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]:


Question: support = import ../development/python-modules/numpy-scipy-support.nix { inherit python; openblas = pkgs.openblasCompat; <del> pkgName = "numpy"; </del> <ins> pkgName = "scipy"; </ins> }; in buildPythonPackage rec { name = "scipy-${version}";

As noted by scipy uses the wrong tests. Instead of running its own test-suite, it runs that of numpy. This is because accidentally pkgName was set to in
Most errors are which are harmless according to
The 12 errors that are encountered are in fact 11 deprecation warnings, and one syntax error in a test when setting PYTHONPATH.


Question: omxplayer = callPackage ../applications/video/omxplayer { }; <del> inherit (python3Packages.callPackage ../applications/networking/onionshare { }) onionshare onionshare-gui; </del> <ins> inherit (callPackage ../applications/networking/onionshare { }) onionshare onionshare-gui; </ins> openambit = qt5.callPackage ../applications/misc/openambit { };

Steps to reproduce the behavior: onionshare <!-- 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 package distutils was remove in Python 3.12. Depends on upsteam. I raised a PR for the fix:


Question: <ins> { lib, ... }: let mainPort = "8080"; in { name = "open-webui"; meta = with lib.maintainers; { maintainers = [ shivaraj-bh ]; }; nodes = { machine = { ... }: { services.open-webui = { enable = true; environment = { # Requires network connection RAG_EMBEDDING_MODEL = ""; }; }; }; }; testScript = '' machine.start() machine.wait_for_unit("open-webui.service") machine.wait_for_open_port(${mainPort}) machine.succeed("curl http://127.0.0.1:${mainPort}") ''; } </ins>

Project description WebUI service for Large Language Models Video demonstration by : .. basically self-hostable ChatGPT-like service Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Additional info Follow-up on for open-webui nixos module. There seems to be an ongoing work on the subject by and on Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Relevant Merge Request:
Just for reference / workaround here's another nix package:
Thanks for that reference. That pdm tool workaround looks a lot more maintainable for the Python backend. Maybe i'll have time to try another PR in the next weeks. In the meantime and as a much simpler UI i packaged as part of PR It would be great if someone could review it.
I would like to mention that in the latest release switched to , I am not sure of any straightforward way to do this while packaging it for .
I just tested your flake, it's impressive, especially the nice UI at the end showing all the processes ! Regarding open-webui, it would be so nice to have that in !!!
Thank you, planning to have more UIs and devShell integration (for CLI tools that interact with ollama). I would love that too! Although there are a few challenges (like the one I pointed above regarding ), I am willing to contribute here. Also, maintainers are quick to respond, in case we need any upstream contributions to make it happen.


Question: src = lib.cleanSource ./.; <del> makeFlags = [ "PANDOC_LUA_FILTERS_DIR=${pkgs.pandoc-lua-filters}/share/pandoc/filters" ]; </del> postPatch = '' ln -s ${doc-support} ./doc-support/result '';

Describe the bug To contribute to the nixpkgs documentation I followed the instructions in the nixpkgs manual "Chapter 21. Contributing to this documentation" and I followed the code snippet Firstly I was greeted with some warnings: But moving on to I saw a large number of errors. It looks like is set up inside the nix-shell but it's not picked up by ? Running the command does work. To Reproduce Expected behavior No warnings, no errors. Metadata Please run and paste the result. Maintainer information:
nix-shell has a specific setup to allow running stdenv phases such as
That also gives me a bunch of errors as well, but different ones: For a bunch of files. I managed to write some updates to the docs and validated them just using the command, but it's a bit unfortunate that just following the instructions literally doesn't work.
Sorry about that. should fix it.
Thanks, that fixes it for me (tested by setting the env variable manually). Great to see these steps towards making it easier to contribute to the docs.


Question: meta.homepage = "https://github.com/blazkowolf/gruber-darker.nvim/"; }; <ins> grug-far-nvim = buildVimPlugin { pname = "grug-far.nvim"; version = "2024-07-22"; src = fetchFromGitHub { owner = "MagicDuck"; repo = "grug-far.nvim"; rev = "f9a8592b037b761fac6a327bc314e9e3eb47401e"; sha256 = "13aa8s9lxdjiyifj9vmbph6hl9px0spfm36my1j2h41biq5nsx5q"; }; meta.homepage = "https://github.com/MagicDuck/grug-far.nvim/"; }; </ins> gruvbox = buildVimPlugin { pname = "gruvbox"; version = "2023-08-14";

Project description <!-- Describe the project a little: --An UI for search and replace on neovim It has replaced for me Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: '' + optionalString isDarwin '' sed -i '/qemucapabilitiestest/d' tests/meson.build sed -i '/vircryptotest/d' tests/meson.build <ins> sed -i '/domaincapstest/d' tests/meson.build sed -i '/qemufirmwaretest/d' tests/meson.build sed -i '/qemuvhostusertest/d' tests/meson.build </ins> '' + optionalString (isDarwin && isx86_64) '' sed -i '/qemucaps2xmltest/d' tests/meson.build sed -i '/qemuhotplugtest/d' tests/meson.build

On my M1 Mac, with homebrew-installed libvirt / qemu-system-aarch64, I'm able to run the VM defined in the config below without issue. However with libvirt / qemu installed via nix, I get: Some possibly related discussion . Looking at the , they're explicitly setting ; adding this seems to resolve the issue: I'm not sure whether disabling those failing tests is a reasonable thing to do. Steps to reproduce the behavior: to in A clear and concise description of what you expected to happen. Should run without , like it does with homebrew. Please run and paste the result.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
FWIW, I also encountered this issue, and have to use the following workaround: And -ing the efi firmware & vars manually. Fixing this bug can lead to great user experience: virt-manager can work out of box.
Where did you get ?


Question: , wayland-protocols , wlroots_0_17 , xwayland <del> , zig_0_12 </del> <ins> , zig_0_13 </ins> , withManpages ? true , xwaylandSupport ? true }: stdenv.mkDerivation (finalAttrs: { pname = "river"; <del> version = "0.3.2"; </del> <ins> version = "0.3.3"; </ins> outputs = [ "out" ] ++ lib.optionals withManpages [ "man" ];

Package name: river Latest released version: 0.3.3 <!-- Search your package here: --- Current version on the unstable channel: 0.3.2 Current version on the stable/release channel: 0.3.2 <!-- 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]:
3 is only a zig 0.13 compatibility release. It’s blocked by
has been merged, this is not blocked anymore.


Question: <del> diff --git a/Cargo.lock b/Cargo.lock index bc9a0f8..45a74ad 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -2165,7 +2165,7 @@ dependencies = [ [[package]] name = "lapce" -version = "0.0.9" +version = "0.0.10" dependencies = [ "lapce-core", "lapce-proxy", @@ -2173,7 +2173,7 @@ dependencies = [ [[package]] name = "lapce-core" -version = "0.0.9" +version = "0.0.10" dependencies = [ "Inflector", "alacritty_terminal 0.15.0", @@ -2233,7 +2233,7 @@ dependencies = [ [[package]] name = "lapce-proxy" -version = "0.0.9" +version = "0.0.10" dependencies = [ "alacritty_terminal 0.16.0-rc2", "anyhow", </del>

<!-- 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: lapce <!-- 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: 0.0.10 desired version: 0.0.12 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Maybe it will fix the crash:
can you create a pull request?
I am using changes in local build. it is working fine


Question: <xi:include href="nginx.section.xml" /> <xi:include href="opengl.section.xml" /> <xi:include href="shell-helpers.section.xml" /> <del> <xi:include href="steam.xml" /> </del> <ins> <xi:include href="steam.section.xml" /> </ins> <xi:include href="cataclysm-dda.section.xml" /> <xi:include href="urxvt.section.xml" /> <xi:include href="weechat.section.xml" />

This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
I will also work on this


Question: makeWrapper $out/dbeaver/dbeaver $out/bin/dbeaver  --prefix PATH : ${jdk}/bin  <del> --prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath ([ glib gtk3 libXtst ])}  </del> <ins> --prefix LD_LIBRARY_PATH : ${lib.makeLibraryPath ([ glib gtk3 libXtst webkitgtk glib-networking ])}  --prefix GIO_EXTRA_MODULES : "${glib-networking}/lib/gio/modules"  </ins> --prefix XDG_DATA_DIRS : "$GSETTINGS_SCHEMAS_PATH" mkdir -p $out/share/pixmaps

DBeaver has support to show spatial data on a map when the database is capable (e.g. postgres + postgis) but opening "spatial" tab gives this error: Steps to reproduce the behavior: dbeaver to a table that has a geometry, show data "Spatial" on the left A map should be shown This happens on master and 21.05-release, didn't test on 21.11 but I suppose it's the same Maintainer information:
I was able to reproduce the error and have fixed it. This is how the map now looks with a sample polygon taken from !
Wow that was quick! Thank you a lot!