Question:
 <title>GNOME</title>
 <title>Packaging GNOME applications</title> <para> Programs in the GNOME universe are written in various languages but they all use GObject-based libraries like GLib, GTK or GStreamer. These libraries are often modular, relying on looking into certain directories to find their modules. However, due to Nix’s specific file system organization, this will fail without our intervention. Fortunately, the libraries usually allow overriding the directories through environment variables, either natively or thanks to a patch in nixpkgs. <link xlink:href="#fun-wrapProgram">Wrapping</link> the executables to ensure correct paths are available to the application constitutes a significant part of packaging a modern desktop application. In this section, we will describe various modules needed by such applications, environment variables needed to make the modules load, and finally a script that will do the work for us. </para>
 <title>Settings</title> <para> <link xlink:href="https://developer.gnome.org/gio/stable/GSettings.html">GSettings</link> API is often used for storing settings. GSettings schemas are required, to know the type and other metadata of the stored values. GLib looks for <filename>glib-2.0/schemas/gschemas.compiled</filename> files inside the directories of <envar>XDG_DATA_DIRS</envar>. </para> <para> On Linux, GSettings API is implemented using <link xlink:href="https://wiki.gnome.org/Projects/dconf">dconf</link> backend. You will need to add <literal>dconf</literal> GIO module to <envar>GIO_EXTRA_MODULES</envar> variable, otherwise the <literal>memory</literal> backend will be used and the saved settings will not be persistent. </para> <para> Last you will need the dconf database D-Bus service itself. You can enable it using <option>programs.dconf.enable</option>. </para> <para> Some applications will also require <package>gsettings-desktop-schemas</package> for things like reading proxy configuration or user interface customization. This dependency is often not mentioned by upstream, you should grep for <literal>org.gnome.desktop</literal> and <literal>org.gnome.system</literal> to see if the schemas are needed. </para>

 <title>Icons</title> <para> When an application uses icons, an icon theme should be available in <envar>XDG_DATA_DIRS</envar>. The package for the default, icon-less <link xlink:href="https://www.freedesktop.org/wiki/Software/icon-theme/">hicolor-icon-theme</link> contains <link linkend="ssec-gnome-hooks-hicolor-icon-theme">a setup hook</link> that will pick up icon themes from <literal>buildInputs</literal> and pass it to our wrapper. Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed. </para>

 <title>GTK Themes</title> <para> Previously, a GTK theme needed to be in <envar>XDG_DATA_DIRS</envar>. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for <link xlink:href="https://elementary.io/docs/human-interface-guidelines#human-interface-guidelines">elementary HIG</link>) might require a special theme like <package>pantheon.elementary-gtk-theme</package>. </para>

 <title>GObject introspection typelibs</title> <para> <link xlink:href="https://wiki.gnome.org/Projects/GObjectIntrospection">GObject introspection</link> allows applications to use C libraries in other languages easily. It does this through <literal>typelib</literal> files searched in <envar>GI_TYPELIB_PATH</envar>. </para>

 <title>Various plug-ins</title> <para> If your application uses <link xlink:href="https://gstreamer.freedesktop.org/">GStreamer</link> or <link xlink:href="https://wiki.gnome.org/Projects/Grilo">Grilo</link>, you should set <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> and <envar>GRL_PLUGIN_PATH</envar>, respectively. </para>

 <title>Onto <package>wrapGAppsHook</package></title> <para> Given the requirements above, the package expression would become messy quickly: <programlisting> preFixup = '' for f in $(find $out/bin/ $out/libexec/ -type f -executable); do wrapProgram "$f"  --prefix GIO_EXTRA_MODULES : "${getLib gnome3.dconf}/lib/gio/modules"  --prefix XDG_DATA_DIRS : "$out/share"  --prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}"  --prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}"  --prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share"  --prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}" done ''; </programlisting> Fortunately, there is <package>wrapGAppsHook</package>, that does the wrapping for us. In particular, it works in conjunction with other setup hooks that will populate the variable: <itemizedlist> <listitem xml:id="ssec-gnome-hooks-wrapgappshook"> <para> <package>wrapGAppsHook</package> itself will add the package’s <filename>share</filename> directory to <envar>XDG_DATA_DIRS</envar>. </para> </listitem> <listitem xml:id="ssec-gnome-hooks-glib"> <para> <package>glib</package> setup hook will populate <envar>GSETTINGS_SCHEMAS_PATH</envar> and then <package>wrapGAppsHook</package> will prepend it to <envar>XDG_DATA_DIRS</envar>. </para> </listitem> <listitem xml:id="ssec-gnome-hooks-dconf"> <para> <package>gnome3.dconf.lib</package> is a dependency of <package>wrapGAppsHook</package>, which then also adds it to the <envar>GIO_EXTRA_MODULES</envar> variable. </para> </listitem> <listitem xml:id="ssec-gnome-hooks-hicolor-icon-theme"> <para> <package>hicolor-icon-theme</package>’s setup hook will add icon themes to <envar>XDG_ICON_DIRS</envar> which is prepended to <envar>XDG_DATA_DIRS</envar> by <package>wrapGAppsHook</package>. </para> </listitem> <listitem xml:id="ssec-gnome-hooks-gobject-introspection"> <para> <package>gobject-introspection</package> setup hook populates <envar>GI_TYPELIB_PATH</envar> variable with <filename>lib/girepository-1.0</filename> directories of dependencies, which is then added to wrapper by <package>wrapGAppsHook</package>. It also adds <filename>share</filename> directories of dependencies to <envar>XDG_DATA_DIRS</envar>, which is intended to promote GIR files but it also <link xlink:href="https://github.com/NixOS/nixpkgs/issues/32790">pollutes the closures</link> of packages using <package>wrapGAppsHook</package>. </para> <warning> <para> The setup hook <link xlink:href="https://github.com/NixOS/nixpkgs/issues/56943">currently</link> does not work in expressions with <literal>strictDeps</literal> enabled, like Python packages. In those cases, you will need to disable it with strictDeps = false;. </para> </warning> </listitem> <listitem xml:id="ssec-gnome-hooks-gst-grl-plugins"> <para> Setup hooks of <package>gst_all_1.gstreamer</package> and <package>gnome3.grilo</package> will populate the <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> and <envar>GRL_PLUGIN_PATH</envar> variables, respectively, which will then be added to the wrapper by <literal>wrapGAppsHook</literal>. </para> </listitem> </itemizedlist> </para> <para> You can also pass additional arguments to <literal>makeWrapper</literal> using <literal>gappsWrapperArgs</literal> in <literal>preFixup</literal> hook: <programlisting> preFixup = '' gappsWrapperArgs+=( # Thumbnailers --prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share" --prefix XDG_DATA_DIRS : "${librsvg}/share" --prefix XDG_DATA_DIRS : "${shared-mime-info}/share" ) ''; </programlisting> </para>

 <title>Updating GNOME packages</title> <para> Most GNOME package offer <link linkend="var-passthru-updateScript"><literal>updateScript</literal></link>, it is therefore possible to update to latest source tarball by running <command>nix-shell maintainers/scripts/update.nix --argstr package gnome3.nautilus</command> or even en masse with <command>nix-shell maintainers/scripts/update.nix --argstr path gnome3</command>. Read the package’s <filename>NEWS</filename> file to see what changed. </para>

 <title>Frequently encountered issues</title> <variablelist> <varlistentry xml:id="ssec-gnome-common-issues-no-schemas"> <term> <computeroutput>GLib-GIO-ERROR **: <replaceable>06:04:50.903</replaceable>: No GSettings schemas are installed on the system</computeroutput> </term> <listitem> <para> There are no schemas avalable in <envar>XDG_DATA_DIRS</envar>. Temporarily add a random package containing schemas like <package>gsettings-desktop-schemas</package> to <literal>buildInputs</literal>. <link linkend="ssec-gnome-hooks-glib"><package>glib</package></link> and <link linkend="ssec-gnome-hooks-wrapgappshook"><package>wrapGAppsHook</package></link> setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the <link linkend="ssec-gnome-common-issues-missing-schema">next error</link>. Or you can try looking through the source code for the actual schemas used. </para> </listitem> </varlistentry> <varlistentry xml:id="ssec-gnome-common-issues-missing-schema"> <term> <computeroutput>GLib-GIO-ERROR **: <replaceable>06:04:50.903</replaceable>: Settings schema ‘<replaceable>org.gnome.foo</replaceable>’ is not installed</computeroutput> </term> <listitem> <para> Package is missing some GSettings schemas. You can find out the package containing the schema with <command>nix-locate <replaceable>org.gnome.foo</replaceable>.gschema.xml</command> and let the hooks handle the wrapping as <link linkend="ssec-gnome-common-issues-no-schemas">above</link>. </para> </listitem> </varlistentry> <varlistentry xml:id="ssec-gnome-common-issues-double-wrapped"> <term> When using <package>wrapGAppsHook</package> with special derivers you can end up with double wrapped binaries. </term> <listitem> <para> This is because derivers like <function>python.pkgs.buildPythonApplication</function> or <function>qt5.mkDerivation</function> have setup-hooks automatically added that produce wrappers with <package>makeWrapper</package>. The simplest way to workaround that is to disable the <package>wrapGAppsHook</package> automatic wrapping with dontWrapGApps = true; and pass the arguments it intended to pass to <package>makeWrapper</package> to another. </para> <para> In the case of a Python application it could look like: <programlisting> python3.pkgs.buildPythonApplication { pname = "gnome-music"; version = "3.32.2"; nativeBuildInputs = [ wrapGAppsHook gobject-introspection ... ]; dontWrapGApps = true; # Arguments to be passed to `makeWrapper`, only used by buildPython* makeWrapperArgs = [ "${gappsWrapperArgs[@]}" ]; } </programlisting> And for a QT app like: <programlisting> mkDerivation { pname = "calibre"; version = "3.47.0"; nativeBuildInputs = [ wrapGAppsHook qmake ... ]; dontWrapGApps = true; # Arguments to be passed to `makeWrapper`, only used by qt5’s mkDerivation qtWrapperArgs [ "${gappsWrapperArgs[@]}" ]; } </programlisting> </para> </listitem> </varlistentry> <varlistentry xml:id="ssec-gnome-common-issues-unwrappable-package"> <term> I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension. </term> <listitem> <para> You can rely on applications depending on the library set the necessary environment variables but that it often easy to miss. Instead we recommend to patch the paths in the source code whenever possible. Here are some examples: <itemizedlist> <listitem xml:id="ssec-gnome-common-issues-unwrappable-package-gnome-shell-ext"> <para> <link xlink:href="https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/gnome-3/core/gnome-shell-extensions/default.nix#L21-L24">Replacing a <envar>GI_TYPELIB_PATH</envar> in GNOME Shell extension</link> – we are using <function>substituteAll</function> to include the path to a typelib into a patch. </para> </listitem> <listitem xml:id="ssec-gnome-common-issues-unwrappable-package-gsettings"> <para> The following examples are hardcoding GSettings schema paths. To get the schema paths we use the functions <itemizedlist> <listitem> <para> <function>glib.getSchemaPath</function> Takes a nix package attribute as an argument. </para> </listitem> <listitem> <para> <function>glib.makeSchemaPath</function> Takes a package output like <literal>$out</literal> and a derivation name. You should use this if the schemas you need to hardcode are in the same derivation. </para> </listitem> </itemizedlist> </para> <para xml:id="ssec-gnome-common-issues-unwrappable-package-gsettings-vala"> <link xlink:href="https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/pantheon/apps/elementary-files/default.nix#L78-L86">Hard-coding GSettings schema path in Vala plug-in (dynamically loaded library)</link> – here, <function>substituteAll</function> cannot be used since the schema comes from the same package preventing us from pass its path to the function, probably due to a <link xlink:href="https://github.com/NixOS/nix/issues/1846">Nix bug</link>. </para> <para xml:id="ssec-gnome-common-issues-unwrappable-package-gsettings-c"> <link xlink:href="https://github.com/NixOS/nixpkgs/blob/29c120c065d03b000224872251bed93932d42412/pkgs/development/libraries/glib-networking/default.nix#L31-L34">Hard-coding GSettings schema path in C library</link> – nothing special other than using <link xlink:href="https://github.com/NixOS/nixpkgs/pull/67957#issuecomment-527717467">Coccinelle patch</link> to generate the patch itself. </para> </listitem> </itemizedlist> </para> </listitem> </varlistentry> </variablelist>

I just found out about wrapGAppsHook by examining a gnome package, but there really should be documentation about this in the Nixpkgs User Guide (a section about Gnome would be nice, which would show the right way to package GTK3 / GTK2 glib based apps). Also, perhaps there are other things I missed that one should know when packaging Gnome Applications or GTK3/2 apps? /cc Gnome maintainers
I'd like to know as well. Currently receiving this error: On one of the packages I'm trying to put into nixpkgs. Apparently sometimes you need for buildInputs. So apparently all you need to do to use this is:
The error occurs when you do not have any directory containing in variable. One of the things does is (which usually contains the aforementioned file) of dependencies to . (Actually this happens in cooperation with via variable.) Icon themes work in the same vein, only is used and it is populated by which is propagated to (). (XDG fallback theme) should be probably to any GTK application that uses icons (I think that is every GTK applicaton nowadays due to CSD) but some applications require Adwaita because they use icons not in hicolor. Not sure if this functions correctly though, at least it should not according to my mental model of how icon theme selection works; I will need to read the relevant XDG spec before I can finish the documentation.
Just thought I'd leave this comment here for future reference: if you get an error like for python gtk applications, try adding to propogatedBuildInputs!
It should go to , though. But be wary of


Question: <del> ;;; NixOS specific load-path (setq load-path (append (reverse (mapcar (lambda (x) (concat x "/share/emacs/site-lisp/")) (split-string (or (getenv "NIX_PROFILES") "")))) load-path)) </del> <ins> (defun nix--profile-paths () "Returns a list of all paths in the NIX_PROFILES environment variable, ordered from more-specific (the user profile) to the least specific (the system profile)" (reverse (split-string (or (getenv "NIX_PROFILES") "")))) ;;; Extend `load-path' to search for elisp files in subdirectories of ;;; all folders in `NIX_PROFILES'. Also search for one level of ;;; subdirectories in these directories to handle multi-file libraries ;;; like `mu4e'.' (require 'seq) (let* ((subdirectory-sites (lambda (site-lisp) (when (file-exists-p site-lisp) (seq-filter (lambda (f) (file-directory-p (file-truename f))) ;; Returns all files in `site-lisp', excluding `.' and `..' (directory-files site-lisp 'full "^([^.]|.[^.]|...)"))))) (paths (apply #'append (mapcar (lambda (profile-dir) (let ((site-lisp (concat profile-dir "/share/emacs/site-lisp/"))) (cons site-lisp (funcall subdirectory-sites site-lisp)))) (nix--profile-paths))))) (setq load-path (append paths load-path))) </ins> ;;; Make `woman' find the man pages (eval-after-load 'woman '(setq woman-manpath <del> (append (reverse (mapcar (lambda (x) (concat x "/share/man/")) (split-string (or (getenv "NIX_PROFILES") "")))) </del> <ins> (append (mapcar (lambda (x) (concat x "/share/man/")) (nix--profile-paths)) </ins> woman-manpath))) ;;; Make tramp work for remote NixOS machines (eval-after-load 'tramp <ins> ;; TODO: We should also add the other `NIX_PROFILES' to this path. ;; However, these are user-specific, so we would need to discover ;; them dynamically after connecting via `tramp' </ins> '(add-to-list 'tramp-remote-path "/run/current-system/sw/bin")) ;;; C source directory

Many Emacs packages, for instance mu4e, move their -files into a subdirectory of . Nixpkgs currently only adds all files located in to the load-path but does not add the files in its subdirectories. This currently makes mu4e from Nixpkgs unusable (by default). We have to fix this snippet of code: E.g. will not make mu4e available within GNU Emacs.
I'll give it a try in a few minutes
Why can't somebody just fix mu4e instead of making emacs startup slower? Like make a wrapper for it like has for Agda or just put files into a correct place like package does? I see wanted to do this, but then changed its mind :(
This actually seems to be the default behavior for Emacs - at least for packages it ships with. See for an example or run to check the default value of (it includes subdirectories)
I see. Okay then. Still, personally I would prefer packages to separate their emacs things into a separate package or at least a separate output.
This broke the package which have subdirectories that include "non-public" files, which gets required as the wrong package for , etc. See Perhaps this should be revisited? I am not sure if this potentially breaks some other packages.
I have reverted this locally (or at least I think so, could be that the change was not propagated somehow), but still seems like paths are , I see a lot of projects test directories being to the e.t.c.
Here is an example of bad load-path and this is just a subset of them all, nix-shell to reproduce:


Question: # which cannot be set at the same time as -Wformat-security hardeningDisable = [ "format" ]; <del> patches = [ # Fix build with bison-3.7: https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?id=1a53f599 (fetchpatch { name = "qtwebengine-bison-3.7-build.patch"; url = "https://code.qt.io/cgit/qt/qtwebengine-chromium.git/patch/?id=1a53f599"; sha256 = "1nqpyn5fq37q7i9nasag6i14lnz0d7sld5ikqhlm8qwq9d7gbmjy"; stripLen = 1; extraPrefix = "src/3rdparty/"; }) ]; </del> postPatch = # Patch Chromium build tools '' ( cd src/3rdparty/chromium; patchShebangs . ) '' <del> # Patch Chromium build files + optionalString (lib.versionOlder qtCompatVersion "5.12") '' substituteInPlace ./src/3rdparty/chromium/build/common.gypi --replace /bin/echo ${coreutils}/bin/echo substituteInPlace ./src/3rdparty/chromium/v8/gypfiles/toolchain.gypi  --replace /bin/echo ${coreutils}/bin/echo substituteInPlace ./src/3rdparty/chromium/v8/gypfiles/standalone.gypi  --replace /bin/echo ${coreutils}/bin/echo '' </del> # Prevent Chromium build script from making the path to `clang` relative to # the build directory.  `clang_base_path` is the value of `QMAKE_CLANG_DIR` # from `src/core/config/mac_osx.pri`.

Describe the bug qtwebengine fails just after successfully configuring with error message To Reproduce ` Expected behavior should compile Notify maintainers Metadata
Pull request works on my machine. Thx.


Question: qtWrapperArgs = lib.optionals stdenv.isLinux [ "--prefix LD_LIBRARY_PATH : ${vulkan-loader}/lib" <ins> # https://bugs.dolphin-emu.org/issues/11807 # The .desktop file should already set this, but Dolphin may be launched in other ways "--set QT_QPA_PLATFORM xcb" </ins> ]; # - Allow Dolphin to use nix-provided libraries instead of building them

The derivation of creates a different .desktop file from the "official" one that has a different name. This is probably done in order to differentiate the two versions of in case someone installs both of them, but the problem is that while it creates a new one, it doesn't delete the "official" one. Also, the new .desktop file should also set , otherwise games don't launch in Wayland. (Though maybe it should be a wrapper instead) (And, unrelated, but why and not ?) The same also applies to PATH: there are both and (which is a link made by the derivation to in the folder). For consistency, there should be made a , otherwise if both dolphins are installed, one overwrites the other in PATH. Steps to reproduce the behavior: dolphinEmuMaster; an app launcher; are both the original "Dolphin Emulator" and the new "Dolphin Emulator (master)" that open the same app (the master one doesn't set `QTQPAPLATFORM=xcb). PATH there are both and (which is a link). There should only be the "Dolphin Emulator (master)" desktop file, and in PATH there should be only (and instead of ). <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --


Question: cups-pdf = handleTest ./cups-pdf.nix {}; custom-ca = handleTest ./custom-ca.nix {}; croc = handleTest ./croc.nix {}; <ins> darling = handleTest ./darling.nix {}; </ins> deepin = handleTest ./deepin.nix {}; deluge = handleTest ./deluge.nix {}; dendrite = handleTest ./matrix/dendrite.nix {};

Darling is a compatibility layer for running macOS apps on Linux (think Wine for macOS). I think it would be interesting to work on with macOS support. They have reverse engineered some headers that Apple doesn't release publicly so having them in "libdarling" could be useful.
We already have this part:
Just heard of Darling. I would be delighted if it could be used for running builds on NixOS!
It seem to be packaged by but only for macOS. If i understand the project correctly, that makes no sense. We want it on linux, to run macOS apps. Also, the package has no version. That's probably because they havn't tagged a version yet. So this is pre-alpha state software. could you update the package to the commit the "stable" AUR package uses and add a version as described here: ? Then we can close this issue.
It looks like the project has started using tagged versions:
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 .
I'd still be very interested in seeing this , especially with the hope of future cross-compilation support
This would even make it possible to package Mac binaries for Linux!
I'm interested in this so that I can test cross compiled binaries when running tests.
I marked this as stale due to inactivity. →
Not stale!!
darling-dmg is just part of . To be exact, it is included as a submodule in the source tree of darling. The darling build will come with kernel modules. It would need someone with kernel-packaging experience to pack it into Nixpkgs. Build instructions in the Darling Docs:
I marked this as stale due to inactivity.


Question: cups-pdf = handleTest ./cups-pdf.nix {}; custom-ca = handleTest ./custom-ca.nix {}; croc = handleTest ./croc.nix {}; <ins> darling = handleTest ./darling.nix {}; </ins> deepin = handleTest ./deepin.nix {}; deluge = handleTest ./deluge.nix {}; dendrite = handleTest ./matrix/dendrite.nix {};

→
I'd still like to see this, though largely for much the same reason Andrew mentions at this point -- I've started working with zig and being able to test cross-compiled macos binaries would be brilliant.
I have got most of a Darling build file running, but I have found an interesting issue. Wever I build I get the following error: From this cmake file: As far as I can tell, the command is a special MacOS thing, and I unfortunately do not understand CMake well enough to fix it...
Well, turns out the issue is that Darling relies on git-submodules, and it looks like this must be built against the Git repo directly, not against the released tarball...
What would therefore be a derivation?
What do you mean It's just a with .
I tried to re-package the prebuilt deb from darling GitHub releases. Here is the nix code darling- Save these 2 snippets as and darling-, then run . With 2 problems: needs setuid/setgid perms, while nix-build would fail if dpkg-deb -x executed directly. I use fakeroot to ignore this problem. always fails. I am not a darling expert, have no idea.
Ah, fantastic, thanks! Looking forward to having this in nixpkgs anyway, but let's see how we go there.
It could be named when entering Nixpkgs.
Good suggestion. I've edited those two scripts.
I got as far as finding out that darlingserver doesn't start with that script because it expects /usr/bin, so updating my to a version, the next issue was that darlingserver was trying to mount overlayfs on "lowerdir=/usr/libexec/darling,up" (may be incomplete, this is strace output) which did not exist.
After a bit of tinkering I got Darling to build from source. I opened with more info. Please give it a try!
It seems that they now use instead of the kernel module. This would make packaging easier.
What's the purpose of ? If it is only the sandbox part of Darling, a new name like would bring less confusion. Update: Opened PR to do the renaming.


Question: <del> { lib, stdenv </del> <ins> { lib , stdenv </ins> , fetchurl , dpkg , undmg

Describe the bug Starting slack doesn't show the window in 8 out of 10 runs To Reproduce Steps to reproduce the behavior: Expected behavior Slack window should open Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. 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 system: host os: multi-user?: sandbox: version: channels(ymatsiuk): channels(root): nixpkgs: Maintainer information:


Question: <ins> { stdenv , fetchFromGitLab , extra-cmake-modules , botan2 , karchive , kauth , libdrm , mesa-demos , procps , utillinux , vulkan-tools , qtbase , qtcharts , qtquickcontrols2 , qtsvg , qttools , qtxmlpatterns , wrapQtAppsHook } : stdenv.mkDerivation rec{ pname = "corectrl"; version = "1.1.1"; src = fetchFromGitLab { owner = "corectrl"; repo = "corectrl"; rev = "v${version}"; sha256 = "sha256-YQDrxPqCa3OzNKd3UiAffqqvOrgbXmDFJGjYPetolyY="; }; nativeBuildInputs = [ extra-cmake-modules wrapQtAppsHook ]; buildInputs = [ botan2 karchive kauth libdrm mesa-demos procps utillinux vulkan-tools qtbase qtcharts qtquickcontrols2 qtsvg qttools qtxmlpatterns ]; runtimeDeps = [ mesa-demos vulkan-tools ]; binPath = stdenv.lib.makeBinPath runtimeDeps; dontWrapQtApps = true; postInstall = '' wrapQtApp $out/bin/corectrl --prefix PATH ":" ${binPath} ''; meta = with stdenv.lib; { homepage = "https://gitlab.com/corectrl/corectrl/"; description = "Control your computer hardware via application profiles"; longDescription = '' CoreCtrl is a Free and Open Source GNU/Linux application that allows you to control with ease your computer hardware using application profiles. It aims to be flexible, comfortable and accessible to regular users. ''; license = licenses.gpl3Plus; platforms = platforms.linux; }; } # TODO: report upstream that libdrm is not detected at configure time </ins>

Project description CoreCtrl is a Free and Open Source GNU/Linux application that allows you to control with ease your computer hardware using application profiles. It aims to be flexible, comfortable and accessible to regular users. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux
It looks very complicated. I will look at AUR.
sorry for the late reply thank you very much for looking into it :relaxed:
Well, I will do what I can do. I am not a huge user and packager of such graphical things, but it looks an interesting project to take on. I will do some research.


Question: nativeCheckInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "scs" ]; <ins> disabledTests = lib.lists.optional (stdenv.system == "x86_64-linux") [ # `test/test_scs_rand.py` hang on "x86_64-linux" (https://github.com/NixOS/nixpkgs/pull/244532#pullrequestreview-1598095858) "test_feasible" "test_infeasibl" "test_unbounded" ]; </ins> meta = with lib; { description = "Python interface for SCS: Splitting Conic Solver";

Project description qpsolvers is python library for solving quadratic programming problems. It contains wrappers for multiple solvers like osqp, cvxopt, quadprog and much more. Metadata homepage URL: source URL: license: LGPLv3 platforms: platform independent (python3.10)
This package wants new version of and new package - . I will try add PR today, but now you can use my NUR repo if you want:


Question: <ins> # Adding Custom Packages {#sec-custom-packages} It's possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the [Nixpkgs manual](https://nixos.org/nixpkgs/manual). In short, you clone Nixpkgs: ```ShellSession $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs ``` Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to [](#opt-environment.systemPackages), e.g. ```nix environment.systemPackages = [ pkgs.my-package ]; ``` and you run `nixos-rebuild`, specifying your own Nixpkgs tree: ```ShellSession # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs ``` The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the [GNU Hello](https://www.gnu.org/software/hello/) package directly in `configuration.nix`: ```nix environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; }; in [ my-hello ]; ``` Of course, you can also move the definition of `my-hello` into a separate Nix expression, e.g. ```nix environment.systemPackages = [ (import ./my-hello.nix) ]; ``` where `my-hello.nix` contains: ```nix with import <nixpkgs> {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; } ``` This allows testing the package easily: ```ShellSession $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! ``` </ins>

This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.


Question: <ins> # Adding Custom Packages {#sec-custom-packages} It's possible that a package you need is not available in NixOS. In that case, you can do two things. First, you can clone the Nixpkgs repository, add the package to your clone, and (optionally) submit a patch or pull request to have it accepted into the main Nixpkgs repository. This is described in detail in the [Nixpkgs manual](https://nixos.org/nixpkgs/manual). In short, you clone Nixpkgs: ```ShellSession $ git clone https://github.com/NixOS/nixpkgs $ cd nixpkgs ``` Then you write and test the package as described in the Nixpkgs manual. Finally, you add it to [](#opt-environment.systemPackages), e.g. ```nix environment.systemPackages = [ pkgs.my-package ]; ``` and you run `nixos-rebuild`, specifying your own Nixpkgs tree: ```ShellSession # nixos-rebuild switch -I nixpkgs=/path/to/my/nixpkgs ``` The second possibility is to add the package outside of the Nixpkgs tree. For instance, here is how you specify a build of the [GNU Hello](https://www.gnu.org/software/hello/) package directly in `configuration.nix`: ```nix environment.systemPackages = let my-hello = with pkgs; stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; }; in [ my-hello ]; ``` Of course, you can also move the definition of `my-hello` into a separate Nix expression, e.g. ```nix environment.systemPackages = [ (import ./my-hello.nix) ]; ``` where `my-hello.nix` contains: ```nix with import <nixpkgs> {}; # bring all of Nixpkgs into scope stdenv.mkDerivation rec { name = "hello-2.8"; src = fetchurl { url = "mirror://gnu/hello/${name}.tar.gz"; sha256 = "0wqd8sjmxfskrflaxywc7gqw7sfawrfvdxd9skxawzfgyy0pzdz6"; }; } ``` This allows testing the package easily: ```ShellSession $ nix-build my-hello.nix $ ./result/bin/hello Hello, world! ``` </ins>

This tracks the conversion of from Docbook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.
I opened a PR for and : PTAL, thanks in advance for reviewing :-)


Question: fetchSubmodules = true; }; <ins> patches = [ # prevents runtime crash when fcitx5-based IM attempts to look in /usr (fetchpatch { name = "use-CMAKE_INSTALL_PREFIX-for-loading-data.patch"; url = "https://github.com/OpenBangla/OpenBangla-Keyboard/commit/f402472780c29eaa6b4cc841a70289adf171462b.diff"; hash = "sha256-YahvtyOxe8F40Wfe+31C6fdmm197QN26/Q67oinOplk="; }) ]; </ins> nativeBuildInputs = [ cmake pkg-config

In the latest stable release, the package fcitx5-openbangla-keyboard does not work. OpenBangla Keyboard package is installed but it does not integrate with fcitx5. fcitx5 crashes every time after logging in.
Here are some screenshots. ! ! !
Thanks for reporting, will take a look.
... Here is my !
Any update? Thanks.
fcitx5 crash log:
I have forked the OpenBangla Keyboard from the develop branch. After the recent commit. it built successfully in NixOS. I am now using OpenBangla Keyboard with an overlay from OpenBangla Keyboard's develop branch. !
I think change of these two lines according to this image will solve the problem. ( I don't know the correct hash = sha256, I just gave this and the correct hash was shown in the build error!) !
Thanks for looking into this. I've pulled the relevant commit and also tested at runtime this time, it does not appear to crash and outputs text properly.


Question: fetchSubmodules = true; }; <ins> patches = [ # prevents runtime crash when fcitx5-based IM attempts to look in /usr (fetchpatch { name = "use-CMAKE_INSTALL_PREFIX-for-loading-data.patch"; url = "https://github.com/OpenBangla/OpenBangla-Keyboard/commit/f402472780c29eaa6b4cc841a70289adf171462b.diff"; hash = "sha256-YahvtyOxe8F40Wfe+31C6fdmm197QN26/Q67oinOplk="; }) ]; </ins> nativeBuildInputs = [ cmake pkg-config

openbangla keyboard installed from the unstable channel does not integrate with fcitx5. It installs just fine but does not integrate with fcitx5. Fcitx5 does not autostart too. OS: NixOS Stable DE: KDE Plasma !
Openbangla keyboard from unstable channel does not work in the unstable nix os installation too. Openbangla keyboard crashes fcitx5 and even if it is restarted switching keyboard layout says openbangla keyboard not available.


Question: sed -i "s|$(DESTDIR)$(PGSQL_BINDIR)|$prefix/bin|g "  "raster/scripts/python/Makefile"; <del> ''; preInstall = '' </del> mkdir -p $out/bin <ins> # postgis' build system assumes it is being installed to the same place as postgresql, and looks # for the postgres binary relative to $PREFIX. We gently support this system using an illusion. ln -s ${postgresql}/bin/postgres $out/bin/postgres </ins> ''; # create aliases for all commands adding version information postInstall = '' <ins> # Teardown the illusory postgres used for building; see postConfigure. rm $out/bin/postgres </ins> for prog in $out/bin/*; do # */ ln -s $prog $prog-${version} done

Describe the bug has , preventing it from being used on other platforms, particularly Darwin in my case. To Reproduce nix-shell to get this error: error: Package ‘postgis-2.5.2’ in is not supported on ‘x8664-darwin’, refusing to evaluate. Expected behavior Produce a postgresql-and-plugins package with postgis available. Additional context Simply allowing doesn't work immediately because PostGIS' build system is quirky. There was some relevant-looking discussion on . Metadata system: host os: multi-user?: sandbox: version: channels(lukeworth): nixpkgs:


Question: ''; cmakeFlags = [ <del> (lib.cmakeBool "USE_DLIB_USE_CUDA" cudaSupport) </del> (lib.cmakeBool "USE_SSE4_INSTRUCTIONS" sse4Support) (lib.cmakeBool "USE_AVX_INSTRUCTIONS" avxSupport) <ins> (lib.cmakeBool "DLIB_USE_CUDA" cudaSupport) ] ++ lib.optionals cudaSupport [ (lib.cmakeFeature "DLIB_USE_CUDA_COMPUTE_CAPABILITIES" (builtins.concatStringsSep "," (with cudaPackages.flags; map dropDot cudaCapabilities))) </ins> ]; <del> nativeBuildInputs = [ cmake pkg-config ]; </del> <ins> nativeBuildInputs = [ cmake pkg-config ] ++ lib.optionals cudaSupport (with cudaPackages; [ cuda_nvcc ]); </ins> buildInputs = [ <del> fftw </del> libpng libjpeg libwebp <del> openblas ] ++ lib.optional guiSupport libX11; </del> <ins> blas lapack ] ++ lib.optionals guiSupport [ libX11 ] ++ lib.optionals config.cudaSupport (with cudaPackages; [ cuda_cudart.dev cuda_cudart.lib cuda_cudart.static cuda_nvcc.dev libcublas.dev libcublas.lib libcublas.static libcurand.dev libcurand.lib libcurand.static libcusolver.dev libcusolver.lib libcusolver.static cudnn.dev cudnn.lib cudnn.static cuda_cccl.dev ]); passthru = { inherit cudaSupport cudaPackages sse4Support avxSupport; }; </ins> meta = with lib; { description = "A general purpose cross-platform C++ machine learning library";

When you set , although it sets the CMAKE flag correctly the resulting package isn't actually built correctly as cmake can't find cuda so it unsets the flag. This is due to the incorrect usage of instead of when building the cuda related packages. The correct usage can be seen in the package. It also tries to build with CUDA by default which is wrong. Dlib hasn't supported fftw since however there are leftover references to it in cmake which might lead people to think it does support fftw. fftw should be removed. As mentioned in this it makes more sense to have as an input into rather that so that people can override it with other BLAS implementations e.g more easily if they want to. The package was also missing lapack which should be . Steps to reproduce the behavior: Build the package, it tries to build with CUDA by default. I made an example with a fairly simple nix flake that let's you switch between my patch and the original package. I have created a which fixes these issues. For it to build with CUDA. How CMAKE fails ! For this simple c switching from my fix to the original bugged package on 23.11 before openblas was . ! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Thanks!


Question: <ins> { lib , buildPythonPackage , python , pythonOlder , fetchFromGitLab , substituteAll , bubblewrap , exiftool , ffmpeg , mime-types , wrapGAppsHook , gdk-pixbuf , gobject-introspection , librsvg , poppler_gi , mutagen , pygobject3 , pycairo , dolphinIntegration ? false, plasma5Packages }: buildPythonPackage rec { pname = "mat2"; version = "0.12.0"; disabled = pythonOlder "3.5"; src = fetchFromGitLab { domain = "0xacab.org"; owner = "jvoisin"; repo = "mat2"; rev = version; sha256 = "0amxwwmcf47dakfm6zvsksv6ja7rz7dpmd1z2rsspy8yds6zgxs7"; }; patches = [ # hardcode paths to some binaries (substituteAll ({ src = ./paths.patch; bwrap = "${bubblewrap}/bin/bwrap"; exiftool = "${exiftool}/bin/exiftool"; ffmpeg = "${ffmpeg}/bin/ffmpeg"; # remove once faf0f8a8a4134edbeec0a73de7f938453444186d is in master mimetypes = "${mime-types}/etc/mime.types"; } // lib.optionalAttrs dolphinIntegration { kdialog = "${plasma5Packages.kdialog}/bin/kdialog"; })) # the executable shouldn't be called .mat2-wrapped ./executable-name.patch # hardcode path to mat2 executable ./tests.patch ]; postPatch = '' substituteInPlace dolphin/mat2.desktop  --replace "@mat2@" "$out/bin/mat2"  --replace "@mat2svg@" "$out/share/icons/hicolor/scalable/apps/mat2.svg" ''; nativeBuildInputs = [ wrapGAppsHook ]; buildInputs = [ gdk-pixbuf gobject-introspection librsvg poppler_gi ]; propagatedBuildInputs = [ mutagen pygobject3 pycairo ]; postInstall = '' install -Dm 444 data/mat2.svg -t "$out/share/icons/hicolor/scalable/apps" install -Dm 444 doc/mat2.1 -t "$out/share/man/man1" install -Dm 444 nautilus/mat2.py -t "$out/share/nautilus-python/extensions" buildPythonPath "$out $pythonPath" patchPythonScript "$out/share/nautilus-python/extensions/mat2.py" '' + lib.optionalString dolphinIntegration '' install -Dm 444 dolphin/mat2.desktop -t "$out/share/kservices5/ServiceMenus" ''; checkPhase = '' ${python.interpreter} -m unittest discover -v ''; meta = with lib; { description = "A handy tool to trash your metadata"; homepage = "https://0xacab.org/jvoisin/mat2"; changelog = "https://0xacab.org/jvoisin/mat2/-/blob/${version}/CHANGELOG.md"; license = licenses.lgpl3Plus; maintainers = with maintainers; [ dotlambda ]; }; } </ins>

Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection


Question: ''; }; <ins> jshint = nodePackages.jshint.override { buildInputs = [ pkgs.phantomjs2 ]; }; </ins> dat = nodePackages.dat.override { buildInputs = [ nodePackages.node-gyp-build ]; };

Reproducing is pretty simple: . The error is: system: host os: multi-user?: sandbox: version: channels(philipp): channels(root): nixpkgs:


Question: --> <para> <del> By default, PostgreSQL stores its databases in <filename>/var/lib/postgresql/$psqlSchema</filename>. You can override this using <xref linkend="opt-services.postgresql.dataDir"/>, e.g. </del> <ins> By default, PostgreSQL stores its databases in <filename>/var/lib/postgresql/$psqlSchema</filename>. You can override this using <xref linkend="opt-services.postgresql.dataDir"/>, e.g. </ins> <programlisting> <xref linkend="opt-services.postgresql.dataDir"/> = "/data/postgresql"; </programlisting>

to newer version to different directory as under postgresql user Output I get:
The NixOS service module for PostgreSQL, for some unfathomable reason, initializes new databases using a non-standard superuser role name ( instead of ). This makes it a nightmare to get to work right, so forget that. Instead: back to your old version of postgresql root, dump your entire database to a file somewhere: to the new version of postgresql root, read in the database dump: (you'll likely see an error go by about the role already existing, you can ignore this) For good measure I went and tested this upgrading a 9.2 database to 9.4 under NixOS, worked fine, the applications using it continued on as normal after the import. That said, the real issue here is: why are we initializing databases using a non-standard install / superuser role name?
cc
See regarding the superuser role name.
Shouldn't we switch the default user to "postgres" on new databases and keep the "root" account around for existing-ones ? See
I strongly agree we should switch the default superuser to . Currently, it seems impossible to use to upgrade postgresql databases due to NixOS using the superuser: simply refuses to run as root.
The approach given by above doesn't work for me:
I can submit the change as a PR but don't use postgresql and it needs testing. Feel free to steal it and do the upgrade process with it.
pgdumpall tends to e pretty useless if you database isn't tiny_ :(
that would be a good start :)
there you go :)
FYI: I've just tested migrating 9.2 to 9.6 using and it works flawlessly.
Ok, I think I found out why wasn't working for me, like I mentioned in It seems to be due to this line in the Hydra module: If I change the mapping to then the command works fine. But I'm not exactly sure what are the implications of doing this, or why was mapped to in the first place...
In case someone runs into the same issue as me, I am documenting the procedure I used to upgrade a PostgreSQL database that was being used (only) for Hydra.


Question: --> <para> <del> By default, PostgreSQL stores its databases in <filename>/var/lib/postgresql/$psqlSchema</filename>. You can override this using <xref linkend="opt-services.postgresql.dataDir"/>, e.g. </del> <ins> By default, PostgreSQL stores its databases in <filename>/var/lib/postgresql/$psqlSchema</filename>. You can override this using <xref linkend="opt-services.postgresql.dataDir"/>, e.g. </ins> <programlisting> <xref linkend="opt-services.postgresql.dataDir"/> = "/data/postgresql"; </programlisting>

I tried to follow procedure above, but as I mentioned before, to use as suggested I needed to change the PostgreSQL user mapping in the Hydra module as specified in my comment just above this one, otherwise I would get a message. However, to read the database dump back into the new PostgreSQL installation I had to change the user mapping as follows: ... and then, after activating the configuration, I needed to run the command in the following way (as root): After doing this, the upgrade from PostgreSQL 9.4 to 9.6 seems to have completed successfully.
Related
If anyone else stumbles on this, pgupgrade seems to work now. I realized after upgrade that my db got reinitialized, so steps for me were much more brutish than that post, but in a nutshell: with new postgresql running, clear whatever got reinitialized (pgupgrade won't run if there are data around, but won't tell you what to remove... lists databases, don't know how to list users, I guessed) drop database whatever; drop user whatever; stop postgresql.service figure path for old binaries, e.g. and copy it somewhere. run the actual pgupgrade as user: restart the postgresql service if all went well after some testing pgupgrade suggests removing the old db with (disclaimer: Don't blame me if that eats your data)


Question: <ins> { lib , pkgs , alsa-lib , plugins ? [ pkgs.alsa-plugins ] , lndir , symlinkJoin , runCommand }: let merged = symlinkJoin { name = "alsa-plugins-merged"; paths = plugins; }; in runCommand "${alsa-lib.pname}-${alsa-lib.version}" { meta = with lib; { description = "wrapper to ease access to ALSA plugins"; platforms = platforms.linux; maintainers = with maintainers; [ gm6k ]; }; outputs = alsa-lib.outputs; } ( ( lib.concatMapStringsSep "n" ( output: '' mkdir ${builtins.placeholder output} ${lndir}/bin/lndir ${lib.attrByPath [output] null alsa-lib}  ${builtins.placeholder output} '' ) alsa-lib.outputs ) + '' cp -r ${merged}/lib/alsa-lib $out/lib ( echo $out | wc -c echo ${alsa-lib} | wc -c ) | xargs echo | grep -q "^(.*) 1$" || ( echo cannot binary patch exit 1 ) rm $out/lib/libasound.la rm $out/lib/libasound.so.?.?.? rm $dev/lib/pkgconfig/alsa.pc rm $dev/nix-support/propagated-build-inputs cp ${alsa-lib}/lib/libasound.la $out/lib cp ${alsa-lib}/lib/libasound.so.?.?.? $out/lib cp ${alsa-lib.dev}/lib/pkgconfig/alsa.pc $dev/lib/pkgconfig cp ${alsa-lib.dev}/nix-support/propagated-build-inputs $dev/nix-support sed -i  $out/lib/libasound.la  $out/lib/libasound.so.?.?.?  $dev/lib/pkgconfig/alsa.pc  $dev/nix-support/propagated-build-inputs  -e "s@${alsa-lib}@$out@g" '' ) </ins>

I get errors like: This shared object is provided by derivation, not i.e:
Just some additional info: using the wrapper script provided by doesn't solve it either.
I would like to hear from someone more experienced, but maybe an aggregate package (like for texLive) could solve this.
You are right. I was talking about the PulseAudio plugin simply because I believe that it is the only plugin used by almost everyone. Other plugins are kind of “special”, or “professional” and can be dealt with on per-expression basis, but the PulseAudio plugin should work out of the box without any extra configuration from the user or the expression maintainer.
BTW I just found this topic from 2009 with a relevant discussion: An aggregate package seems to be a viable solution. The problem with this (which seems to be the one concerning in the ML) is that adding plugins won’t be possible without rebuilds.
It's really tricky because ALSAPLUGINDIRS is a compiletime constant in alsa-lib. (so the env-var approach won't work) I tried to add a dir for plugins like for the graphics drivers to /run/alsa-plugins. The problem with this is that alsa-lib builds smixer into ALSAPLUGINDIRS so it has to be inside the derivation. You can pass the configure flag --disable-mixer an then alsa-lib will build, but then gstreamer won't build anymore (i guess it tries to link against the smixer in alsa-lib). I haven't tried the aggregate package yet because I'm not sure how to make everything use the aggregate derivation instead of the alsa-lib.
By the way, looks like should be removed. Looks like there used to be a in Nixpkgs that made respect this environment variable, but now it is .
Shouldn’t the commit that removed the “unused” variable be reverted? I mean, we need a beautiful solution, but at least it worked before that.
All the plugin so-files are relatively small in comparison to libasound (<300 kB together vs. ~1.4 MB), so we might consider having the default attribute contain the plugins needed for pulseaudio playback. Our attribute no longer needs to build, so we should be able to reverse the dependency and make depend on . /cc should know more about pulseaudio packaging. Perhaps it's a similar situation in there.


Question: <ins> { lib , pkgs , alsa-lib , plugins ? [ pkgs.alsa-plugins ] , lndir , symlinkJoin , runCommand }: let merged = symlinkJoin { name = "alsa-plugins-merged"; paths = plugins; }; in runCommand "${alsa-lib.pname}-${alsa-lib.version}" { meta = with lib; { description = "wrapper to ease access to ALSA plugins"; platforms = platforms.linux; maintainers = with maintainers; [ gm6k ]; }; outputs = alsa-lib.outputs; } ( ( lib.concatMapStringsSep "n" ( output: '' mkdir ${builtins.placeholder output} ${lndir}/bin/lndir ${lib.attrByPath [output] null alsa-lib}  ${builtins.placeholder output} '' ) alsa-lib.outputs ) + '' cp -r ${merged}/lib/alsa-lib $out/lib ( echo $out | wc -c echo ${alsa-lib} | wc -c ) | xargs echo | grep -q "^(.*) 1$" || ( echo cannot binary patch exit 1 ) rm $out/lib/libasound.la rm $out/lib/libasound.so.?.?.? rm $dev/lib/pkgconfig/alsa.pc rm $dev/nix-support/propagated-build-inputs cp ${alsa-lib}/lib/libasound.la $out/lib cp ${alsa-lib}/lib/libasound.so.?.?.? $out/lib cp ${alsa-lib.dev}/lib/pkgconfig/alsa.pc $dev/lib/pkgconfig cp ${alsa-lib.dev}/nix-support/propagated-build-inputs $dev/nix-support sed -i  $out/lib/libasound.la  $out/lib/libasound.so.?.?.?  $dev/lib/pkgconfig/alsa.pc  $dev/nix-support/propagated-build-inputs  -e "s@${alsa-lib}@$out@g" '' ) </ins>

I was thinking about integrating the alsaPlugins into the alsaLib derivation altogether. (I need the jack plugin as well) It may not be an elegant solution but it's not that big an overhead (maybe some dependencies will need adjustments) And build all the plugins that are buildable. Also I think the workaround was removed in official alsa project. See Dynamic Loader helpers section here:
I'm using this workaround right now:
Also see , which maybe adds more complexity to this issue because of a 32-bit library / 64-bit plugin mismatch.
(triage) status?
I think I'm seeing an effect of this in attempting to update the Factorio derivation, but master nixpkgs has a more up to date version of alsaLib, but it appears to be trying to load the plugins from the system installed version of alsaPlugins.
I also got hit by this issue while trying to run Nix-installed Audacity 2.2.2 (from nixpkgs master) on Ubuntu 14.04. Audacity playback doesn't make any sound because, it seems, hardcodes its plugin search directory.
I worked around this by creating a directory containing a symbolic link to and adding that directory to .
I've found a workaround in Guix manual alsaPlugins the following lines to ~/.asoundrc or
Wow. Thanks for the tip gnidorah <:
Still relevant in 19.09 :/ Does anyone know the syntax for importing rate conversion plugins ("speexrate", "samplerate", etc.) directly inside "", or if there's a method without hackery by now? Btw, seems to be affected by this, I'm using your workaround from here right now, together with .
Meanwhile it is even ALSAPLUGINDIR instead of ALSAPLUGINDIRS (notice the missing plural 'S')
we could patch like so. But beware, this is actually only for the the second time that i am patching c code. I tried it with and the converter and it's working so far. <details<summaryenvironment-plugin-</summary</details
Or we could just bring back the original patch.


Question: <ins> { lib , pkgs , alsa-lib , plugins ? [ pkgs.alsa-plugins ] , lndir , symlinkJoin , runCommand }: let merged = symlinkJoin { name = "alsa-plugins-merged"; paths = plugins; }; in runCommand "${alsa-lib.pname}-${alsa-lib.version}" { meta = with lib; { description = "wrapper to ease access to ALSA plugins"; platforms = platforms.linux; maintainers = with maintainers; [ gm6k ]; }; outputs = alsa-lib.outputs; } ( ( lib.concatMapStringsSep "n" ( output: '' mkdir ${builtins.placeholder output} ${lndir}/bin/lndir ${lib.attrByPath [output] null alsa-lib}  ${builtins.placeholder output} '' ) alsa-lib.outputs ) + '' cp -r ${merged}/lib/alsa-lib $out/lib ( echo $out | wc -c echo ${alsa-lib} | wc -c ) | xargs echo | grep -q "^(.*) 1$" || ( echo cannot binary patch exit 1 ) rm $out/lib/libasound.la rm $out/lib/libasound.so.?.?.? rm $dev/lib/pkgconfig/alsa.pc rm $dev/nix-support/propagated-build-inputs cp ${alsa-lib}/lib/libasound.la $out/lib cp ${alsa-lib}/lib/libasound.so.?.?.? $out/lib cp ${alsa-lib.dev}/lib/pkgconfig/alsa.pc $dev/lib/pkgconfig cp ${alsa-lib.dev}/nix-support/propagated-build-inputs $dev/nix-support sed -i  $out/lib/libasound.la  $out/lib/libasound.so.?.?.?  $dev/lib/pkgconfig/alsa.pc  $dev/nix-support/propagated-build-inputs  -e "s@${alsa-lib}@$out@g" '' ) </ins>

i guess it is still here (somehow :)) but it is doing nothing for loading rate converters since they are neither loaded through patched from nor through from but through from But yes, now that i reread your comment, that way of telling alsa where to find libs is gone.
Since I opened this issue I'm not sure what to do with it, but since learning more about alsa config this is no longer an issue for me. I'll post my config hoping it helps people: I have in my And my config looks like this: This finds the jack plugin just fine due to the If I want to run something (for example steam) that won't be able to run with jack then I just fallback to my mixing PCM with stopping jack exporting
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
This still needs to be addressed (either by the wrapper or by patching the package, maybe both). I've been using the same trick as and it works well enough, but it'd have been great to have the package itself or the wrapper handle users' additional plugin paths out of the box.
With the release of v1.2.4 on 19 Oct, alsa-lib gained official support for an runtime environment variable. It was in , following with some Guix folks. Note that this environment variable only supports a single directory, unlike the (effectively unused?) alsa-plugin-conf- which provided a plural environment variable.


Question: <ins> { lib , pkgs , alsa-lib , plugins ? [ pkgs.alsa-plugins ] , lndir , symlinkJoin , runCommand }: let merged = symlinkJoin { name = "alsa-plugins-merged"; paths = plugins; }; in runCommand "${alsa-lib.pname}-${alsa-lib.version}" { meta = with lib; { description = "wrapper to ease access to ALSA plugins"; platforms = platforms.linux; maintainers = with maintainers; [ gm6k ]; }; outputs = alsa-lib.outputs; } ( ( lib.concatMapStringsSep "n" ( output: '' mkdir ${builtins.placeholder output} ${lndir}/bin/lndir ${lib.attrByPath [output] null alsa-lib}  ${builtins.placeholder output} '' ) alsa-lib.outputs ) + '' cp -r ${merged}/lib/alsa-lib $out/lib ( echo $out | wc -c echo ${alsa-lib} | wc -c ) | xargs echo | grep -q "^(.*) 1$" || ( echo cannot binary patch exit 1 ) rm $out/lib/libasound.la rm $out/lib/libasound.so.?.?.? rm $dev/lib/pkgconfig/alsa.pc rm $dev/nix-support/propagated-build-inputs cp ${alsa-lib}/lib/libasound.la $out/lib cp ${alsa-lib}/lib/libasound.so.?.?.? $out/lib cp ${alsa-lib.dev}/lib/pkgconfig/alsa.pc $dev/lib/pkgconfig cp ${alsa-lib.dev}/nix-support/propagated-build-inputs $dev/nix-support sed -i  $out/lib/libasound.la  $out/lib/libasound.so.?.?.?  $dev/lib/pkgconfig/alsa.pc  $dev/nix-support/propagated-build-inputs  -e "s@${alsa-lib}@$out@g" '' ) </ins>

One nice effect is that we don't have to patch alsa-libs any more. Thoughts on how to best take advantage of the new feature?
Without writing an updated patch for multiple plugin directory support, the upstream's can probably be put to use immediately by pointing to symlink farm of plugins. Haven't tried this, but I suspect it (or something similar) would do the trick. The linked GUIX thread included review of a patch for multiple plugin directory support. It looked promising but its growing stale with outstanding feedback. They've not responded to news of upstream ; I do wonder if they'd consider contributing their multi-directory patch or not - especially given that there's now some kind of upstream support.
Guix's property will automatically create a create a symlink union of the relevant plugins for single-entry search paths. It's how Chromium extensions and plugins are discovered, for example. It's just because we haven't gotten around to update alsa-lib yet, as it missed the latest 'staging' cycle.
Hi, I'm the author of that patch from Guix, although it grew out my reading of the old unused nixpkgs patch. I ran out of energy for keeping track of all the "C issues" one has to think about... if alsa-lib's new ALSAPLUGINDIR meets our needs then I'll be glad to leave the patch behind. Feel free to use the patch in any way you like — it does work fine and, as a part of Guix, the license is GPL3+. Or, as a part of alsa-lib, maybe it's LGPL2.1+? Anyways, feel free...
I marked this as stale due to inactivity. →
I implemented the aggregate package approach () and appreciate your thoughts on it.


Question: { lib , buildPythonPackage , fetchPypi <del> , mock , nose </del> <ins> , pytestCheckHook , pythonOlder </ins> , requests <del> , yanc </del> }: buildPythonPackage rec { pname = "ovh"; <del> version = "1.0.0"; </del> <ins> version = "1.1.0"; </ins> format = "setuptools"; <ins> disabled = pythonOlder "3.7"; </ins> src = fetchPypi { inherit pname version; <del> hash = "sha256-IQzwu0gwfPNPOLQLCO99KL5Hu2094Y+acQBFXVGzHhU="; </del> <ins> hash = "sha256-EI+bWjtHEZPOSkWJx3gvS8y//gugMWl3TrBHKsKO9nk="; </ins> }; propagatedBuildInputs = [ requests ]; <del> preCheck = '' export HOME=$(mktemp -d) ''; </del> nativeCheckInputs = [ <del> mock nose yanc </del> <ins> pytestCheckHook </ins> ]; <del> # requires network checkPhase = '' nosetests .  -e test_config_get_conf  -e test_config_get_custom_conf  -e test_endpoints  -e test_init_from_custom_config ''; </del> <ins> pythonImportsCheck = [ "ovh" ]; disabledTests = [ # Tests require network access "test_config_from_files" "test_config_from_given_config_file" "test_config_from_invalid_ini_file" "test_config_from_only_one_file" "test_endpoints" ]; </ins> <del> meta = { </del> <ins> meta = with lib; { </ins> description = "Thin wrapper around OVH's APIs"; homepage = "https://github.com/ovh/python-ovh"; <del> license = lib.licenses.bsd2; maintainers = [ lib.maintainers.makefu ]; </del> <ins> changelog = "https://github.com/ovh/python-ovh/blob/v${version}/CHANGELOG.md"; license = licenses.bsd2; maintainers = with maintainers; [ makefu ]; </ins> }; }

Package name: Latest released version: 1.1.0 <!-- Search your package here: --- Current version on the unstable channel: 1.0.0 Current version on the stable/release channel: 1.0.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR.


Question: { stdenv , lib , fetchFromGitHub <ins> , fetchpatch </ins> , substituteAll , cairo , cinnamon-desktop

Restart cinnamon from the panel freezes the desktop, from the journal you will find cinnamon crashes. click the panel trouble shooting cinnamon No crash.
Okay, I guess I need upstream help for this, going to forward this to upstream...


Question: srt systemd taglib <del> wayland wayland-protocols </del> zlib ] ++ (with xorg; [

Packaged VLC does not seem to support wayland. Steps to reproduce the behavior: vlc with on e.g. sway opens as a XWayland window VLC opens as a Wayland native window Not applicable Possibly related to VLC not depending on qtwayland. Please run and paste the result. EDIT: Typo
It is strange. I built it and verified, it is not linked with QT libraries even if they are put as inputs.
Is also pulled in as an input?
Nope. Working on it now. First encounter: Wayland is considered experimental and disabled by default.
Can you test the patch?
Works like a charm, thanks a lot! :)
I'm on NixOS 23.05 and discovered that vlc prefers to use XWayland if var is set. If I unset then vlc starts in Wayland mode. Does anyone know how to make it to start on Wayland by default?
For now I hacked it with: Special thanks to
Well, if this is hardcoded on VLC, there is nothing to do (besides maybe searching some hidden commandline flag).
The "use QTQPAPLATFORM be damned" behavior is apparently just what QT does, and is not specific to VLC
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Here is the updated wrap that also addresses the desktop file


Question: }; }; } <ins> { settings.bind_interface = "eth0"; port = bindTestPort; } </ins> ]; }; };

lists a listener option called that can be used to listen for incoming network connections only on the specified interface. Unfortunately does not accept this option. Steps to reproduce the behavior: This should evaluate cleanly. Incidentally, that assertion message drops the component in the attribute path, it might be nice to fix that.


Question: buildInputs = lib.optionals withMkl [ mkl <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_cudart cudaPackages.libcublas cudaPackages.libcurand ] ++ lib.optionals withCuDNN [ cudaPackages.cudnn </ins> ] ++ lib.optionals withOneDNN [ oneDNN ] ++ lib.optionals withOpenblas [

After setting up faster-whisper for my Home Assistant instance, I learned that my CPU (i5-6500) isn't quite as fast as I'd like for this, so I am now trying to test a GPU (NVIDIA Quadro M2000). My configuration for it is the following: I expected it to then run on my GPU using CUDA, but unless my GPU and CPU are continually equally performant, it is not working. (Also, no processes are shown in ) Steps to reproduce the behavior: NVIDIA GPU, and then configure it accordingly in , add , , , and to faster-whisper in configuration, configure it to work with device = "cuda" for STT to be faster, instead same speed I'm not totally sure what to expect because this is my first time using this, but I expected a Python3 process to appear in and for my STT to be quicker. My config is the following: The following (seemingly) NVIDIA related items are at /dev/ ! ! works, but I am not totally sure that my CUDA is configured correctly, for all I know possibly CUDA isn't configured properly, but I think I have everything correct.
I eyeballed CUDA support, but have no hardware to test or reproduce. I appreciate help in fixing the module to make it work with CUDA.
I am not overly proficient in Nix or anything like this, but I would be willing to help if you have ideas.
Well, for one we're not passing in . Can you try setting ?
Ok, I that and now when looking at the logs, I get this: It then exits.
That looks actionable. We did indeed not build ctranslate2 with CUDA support. I can try to set that up, but it won't be the default, because that would make the package unfree. We possibly need multiple ctranslate2 attributes.
Is it possible to have the package be free unless an option is passed that enables CUDA and then makes it unfree, or would two different packages be needed. There could be a package, I think that could work.
Yeah, that would also work.
If you want to try and build it with CUDA support, I can test it out and report back.
fixes the module, so it passes as expected. It also adds CUDA support to .


Question: buildInputs = lib.optionals withMkl [ mkl <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_cudart cudaPackages.libcublas cudaPackages.libcurand ] ++ lib.optionals withCuDNN [ cudaPackages.cudnn </ins> ] ++ lib.optionals withOneDNN [ oneDNN ] ++ lib.optionals withOpenblas [

Check the description of the PR on how to opt into CUDA support in nixpkgs.
Hi Just to clarify, you only need in your (or in your 's ) if you're setting up a development environment to write cuda programs. If you only want to use packages with cuda support enabled, you just use them directly (e.g. ), no need to add anywhere manually. If you want to enable cuda in every package that supports it, you can set in your (nb: this triggers a massive rebuild). Instead of adding , you want to use (this way if you switch e.g. -, you'd be still using for the correct kernel), but also instead of you can take (keeps working if you switch e.g. -) Sorry we didn't get this documented yet
Wow, thank you! I assume I still need in my , right? About enabling , I've already enabled that and let it go through that whole process, so I think I'll just leave it enabled. About changing the , how is that to be done exactly? Do I just swap for in the exact same spot?
Also, is there an easy way for me to test out this updated package before it gets merged?
Depends on how you deploy your machine and what nixos version you are on.
I'm on Unstable and use Flakes.
You could replace your nixpkgs input with a fork of nixos-unstable and pick the commits from that PR on top. I'm sure there is a better solution, but I'm not well versed in flakes.
No, is the old version of , and you don't need it in Yes, except it's just , without at the end. This refers to "whatever graphics driver is in use". But also you can just remove this if you use and (both options are badly named, they're not really specific to neither of opengl or x11)
I have , but I don't have xserver enabled because this is a headless server. Do I even need nvidia_x11 if it's headless with no DE?
is where comes from; I don't recall now if it's ok to use on a headless machine, but if you like to just be explicit, you can keep P.S.


Question: buildInputs = lib.optionals withMkl [ mkl <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_cudart cudaPackages.libcublas cudaPackages.libcurand ] ++ lib.optionals withCuDNN [ cudaPackages.cudnn </ins> ] ++ lib.optionals withOneDNN [ oneDNN ] ++ lib.optionals withOpenblas [

Discourse and NixOS matrix channels provide venues for Q&A discussions
With the changes made to ctranslate2, and the fixes to th , I fully expect this could work. If not, please get back to me with some error messages, e.g. the hardening of the systemd unit might cause problems.
No problem. I attempted to use just the new packages, but it became a little difficult because my old nixpkgs didn't think that ctranslate2 could have CUDA enabled, so I'll just wait for master to get pushed to NixOS-Unstable (Hopefully soon!)
The package now fails with . My system may not be correctly configured for CUDA support, or the SystemD Service is not passing through the NVIDIA device correctly. Just a reminder, the following devices are available at : (I'm not sure if is an NVIDIA thing, but it exists if that's of importance.)
Then we're at least missing . What's the content of ? nix DeviceAllow = if [ "cuda" "auto" ] then [ # "/dev/nvidia1" "/dev/nvidia2" "/dev/nvidia3" "/dev/nvidia4" "/dev/nvidia-caps/nvidia-cap1" "/dev/nvidia-caps/nvidia-cap2" "/dev/nvidiactl" "/dev/nvidia-modeset" "/dev/nvidia-uvm" "/dev/nvidia-uvm-tools" ] else "";
I modified the SystemD service to include , and it didn't help at all. The contents of are . Also, I just discovered something new. When running I get So possibly updating this system now broke NVIDIA support and it just so happened to be at the same time I tried to get Whisper working.
Did you also check which is in ? There are two things you need to maintain: 1) your driver should be newer than the cuda libraries used to build your program, 2) your should come from the same (version of) package as the kernel modules (in other words, currently you have to reboot if you update your nixos and get a newer - the new kernel module is only loaded on the next boot)
shows the following for Also, I just rebooted and is working.
from what I listed is accessible from , should my system have functional CUDA support? I tried using some testing parts from , but it seems to be out of date.


Question: buildInputs = lib.optionals withMkl [ mkl <ins> ] ++ lib.optionals withCUDA [ cudaPackages.cuda_cudart cudaPackages.libcublas cudaPackages.libcurand ] ++ lib.optionals withCuDNN [ cudaPackages.cudnn </ins> ] ++ lib.optionals withOneDNN [ oneDNN ] ++ lib.optionals withOpenblas [

PS: Should this conversation be continued somewhere else, or is it fine to continue it here because it is somewhat pertinent to the issue?
Yes please, e.g. in or , or on You can just post the final update here once you get things to work, for discoverability purposes. Thanks!


Question: ]; buildInputs = [ <del> attr </del> <ins> bzip2 libcdio libiconv readline </ins> zlib libburn libisofs <ins> ] ++ lib.optionals stdenv.isLinux [ acl attr </ins> ]; <del> propagatedBuildInputs = [ </del> <ins> propagatedBuildInputs = lib.optionals stdenv.isLinux [ </ins> acl ];

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: { lib <ins> , stdenv </ins> , buildPythonPackage , fetchFromGitHub , blas

Project description qpsolvers is python library for solving quadratic programming problems. It contains wrappers for multiple solvers like osqp, cvxopt, quadprog and much more. Metadata homepage URL: source URL: license: LGPLv3 platforms: platform independent (python3.10)
This package wants new version of and new package - . I will try add PR today, but now you can use my NUR repo if you want:


Question: <ins> diff --git a/src/vcpkg/vcpkgpaths.cpp b/src/vcpkg/vcpkgpaths.cpp index 3f588c21..e6f2bbed 100644 --- a/src/vcpkg/vcpkgpaths.cpp +++ b/src/vcpkg/vcpkgpaths.cpp @@ -579,7 +579,8 @@ namespace vcpkg if (!args.do_not_take_lock) { std::error_code ec; -                    const auto vcpkg_root_file = root / ".vcpkg-root"; +                    fs.create_directories(Path{"/tmp/vcpkg"}, VCPKG_LINE_INFO); +                    const auto vcpkg_root_file = Path{"/tmp/vcpkg"} / Hash::get_string_sha256(root.c_str()); if (args.wait_for_lock.value_or(false)) { file_lock_handle = fs.take_exclusive_file_lock(vcpkg_root_file, ec); </ins>

Project description vcpkg is a package manager for C++ and many large and very small libraries are packaged there. Many of my projects use it for CMake configuration and for its toolchain file that automatically download and build libraries. I want to setup dev environment with nix and this is one of the packages I'm looking for that I've been building manually (since the brew packaged vcpkg is not well configured for manifest files support) Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, windows
I'll try something now.
Reading the , it looks like a case for a module, not merely a package.
I'm not sure what's the difference between a package and a module... but if it allows me to download a prebuilt binary of vcpkg that I can simply install, that's fine for me. Know that this package manager is made (partly) in C++ and need compiling. The build script is the you see there.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Maybe I am over-engineering here. Reading the AUR script, vcpkg uses systemd scripts/services. Therefore I think it requires more integration with the operating system. Modules are, roughly speaking, designed to "patch" and configure NixOS (the operating system).
Would be nice to have!
Work is ongoing here:


Question: ++ optionals config.security.pam.enableOTPW [ pkgs.otpw ] ++ optionals config.security.pam.oath.enable [ pkgs.oath-toolkit ] ++ optionals config.security.pam.p11.enable [ pkgs.pam_p11 ] <ins> ++ optionals config.security.pam.enableFscrypt [ pkgs.fscrypt-experimental ] </ins> ++ optionals config.security.pam.u2f.enable [ pkgs.pam_u2f ]; boot.supportedFilesystems = optionals config.security.pam.enableEcryptfs [ "ecryptfs" ];

I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. →


Question: nativeBuildInputs = [ pkg-config <del> ] ++ lib.optionals enablePython [ python3 python3.pkgs.setuptools </del> ] ++ [ sphinx ]; <del> buildInputs = [ acl attr e2fsprogs libuuid lzo python3 udev zlib zstd ]; </del> <ins> buildInputs = [ acl attr e2fsprogs libuuid lzo udev zlib zstd ]; </ins> # gcc bug with -O1 on ARM with gcc 4.8 # This should be fine on all platforms so apply universally

Python module, corresponding to the package and exposing its functionality in Python programs, fails to import, despite being included in . module is imported successfully. n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- (as maintainer) (as the one who exposed the Python bindings) Please run and paste the result.
Note: it seems like the module doesn't work even on commits that introduced it properly... To verify, run in a Nixpkgs checkout:
Yeah, I screwed up testing this. btrfs-progs doesn't propagate python, so I was using my system (non-NixOS) Python installation without noticing. should fix it.


Question: "-Dxml=ON" "-Dxrootd=OFF" ] <del> ++ stdenv.lib.optional (stdenv.cc.libc != null) "-DC_INCLUDE_DIRS=${stdenv.lib.getDev stdenv.cc.libc}/include"; </del> <ins> ++ stdenv.lib.optional (stdenv.cc.libc != null) "-DC_INCLUDE_DIRS=${stdenv.lib.getDev stdenv.cc.libc}/include" ++ stdenv.lib.optional stdenv.isDarwin "-DOPENGL_INCLUDE_DIR=${OpenGL}/Library/Frameworks"; </ins> enableParallelBuilding = true;

I have a system without Command Line Tools or XCode and nix'es cmake can't find headers and tries to pick up system frameworks. Try to build this: On my system I get: System: Darwin Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: 17.09pre-git () Sandboxing enabled: no
Related to


Question: cpp-jwt = callPackage ../development/libraries/cpp-jwt { }; <del> ctranslate2 = callPackage ../development/libraries/ctranslate2 { }; </del> <ins> ctranslate2 = callPackage ../development/libraries/ctranslate2 { stdenv = if pkgs.config.cudaSupport then gcc11Stdenv else stdenv; withCUDA = pkgs.config.cudaSupport; withCuDNN = pkgs.config.cudaSupport; }; </ins> ubus = callPackage ../development/libraries/ubus { };


Question: cpp-jwt = callPackage ../development/libraries/cpp-jwt { }; <del> ctranslate2 = callPackage ../development/libraries/ctranslate2 { }; </del> <ins> ctranslate2 = callPackage ../development/libraries/ctranslate2 { stdenv = if pkgs.config.cudaSupport then gcc11Stdenv else stdenv; withCUDA = pkgs.config.cudaSupport; withCuDNN = pkgs.config.cudaSupport; }; </ins> ubus = callPackage ../development/libraries/ubus { };


Question: cpp-jwt = callPackage ../development/libraries/cpp-jwt { }; <del> ctranslate2 = callPackage ../development/libraries/ctranslate2 { }; </del> <ins> ctranslate2 = callPackage ../development/libraries/ctranslate2 { stdenv = if pkgs.config.cudaSupport then gcc11Stdenv else stdenv; withCUDA = pkgs.config.cudaSupport; withCuDNN = pkgs.config.cudaSupport; }; </ins> ubus = callPackage ../development/libraries/ubus { };


Question: cpp-jwt = callPackage ../development/libraries/cpp-jwt { }; <del> ctranslate2 = callPackage ../development/libraries/ctranslate2 { }; </del> <ins> ctranslate2 = callPackage ../development/libraries/ctranslate2 { stdenv = if pkgs.config.cudaSupport then gcc11Stdenv else stdenv; withCUDA = pkgs.config.cudaSupport; withCuDNN = pkgs.config.cudaSupport; }; </ins> ubus = callPackage ../development/libraries/ubus { };


Question: reverse=True, ) return versions def get_git_hash(self, rev: str): return ( subprocess.check_output( [ <del> "nix-universal-prefetch", "fetchFromGitLab", "--owner", self.owner, "--repo", self.repo, "--rev", rev, </del> <ins> "nix-prefetch-url", "--unpack", f"https://gitlab.com/{self.owner}/{self.repo}/-/archive/{rev}/{self.repo}-{rev}.tar.gz", </ins> ] ) .decode("utf-8")

The gitlab  script depends on , which was removed by in . Steps to reproduce the behavior: The update scripts succeeds. (myself) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Also looks like nix-update could be used here.
Ok. looks like switching to nix-update would require some other major refactoring because the writes out some json file out. But here is a simpler approach:


Question: do [ -d "$targetDir" ] || continue <del> find "$targetDir" -type f -executable -print0 | while IFS= read -r -d '' file </del> <ins> find "$targetDir" ! -type d -executable -print0 | while IFS= read -r -d '' file </ins> do patchelf --print-interpreter "$file" >/dev/null 2>&1 || continue

Describe the bug to the find call. This prevents things in the that are symlinks from being wrapped. Noticed this during office-hours when wasn't wrapped anymore. We should add some code like there is in or revert the . To Reproduce Steps to reproduce the behavior: a binary into or the thing and notice the binary isn't wrapped.


Question: <ins> { lib, stdenv, fetchurl, makeWrapper, jre_headless, gawk, }: stdenv.mkDerivation rec { pname = "nexus"; version = "3.69.0-02"; src = fetchurl { url = "https://download.sonatype.com/nexus/3/nexus-${version}-unix.tar.gz"; hash = "sha256-7sgLPuM93mFEPlTd3qJY+FGVHErvgcTGJWwSBcqBgWI="; }; preferLocalBuild = true; sourceRoot = "${pname}-${version}"; nativeBuildInputs = [ makeWrapper ]; patches = [ ./nexus-bin.patch ./nexus-vm-opts.patch ]; postPatch = '' substituteInPlace bin/nexus.vmoptions  --replace-fail ../sonatype-work /var/lib/sonatype-work  --replace-fail etc/karaf $out/etc/karaf  --replace-fail =. =$out ''; installPhase = '' runHook preInstall mkdir -p $out cp -rfv * .install4j $out rm -fv $out/bin/nexus.bat wrapProgram $out/bin/nexus  --set JAVA_HOME ${jre_headless}  --set ALTERNATIVE_NAME "nexus"  --prefix PATH "${lib.makeBinPath [ gawk ]}" runHook postInstall ''; meta = { description = "Repository manager for binary software components"; homepage = "https://www.sonatype.com/products/sonatype-nexus-oss"; sourceProvenance = with lib.sourceTypes; [ binaryBytecode ]; license = lib.licenses.epl10; platforms = lib.platforms.all; maintainers = with lib.maintainers; [ aespinosa ironpinguin luftmensch-luftmensch zaninime ]; }; } </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: homepage = "https://github.com/nomic-ai/gpt4all"; license = lib.licenses.mit; mainProgram = "gpt4all"; <del> maintainers = with lib.maintainers; [ polygon ]; </del> <ins> maintainers = with lib.maintainers; [ polygon titaniumtown ]; </ins> }; })

Package name: gpt4all Latest released version: 3.2.1 <!-- Search your package here: --- Current version on the unstable channel: 2.8.0 Current version on the stable/release channel: 2.7.5 <!-- 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]:
Hi, I don't maintain GPT4All any longer, I switched to some other technologies (Open-WebUI).
haha, maybe i'll give that one a try then :) ty for all your hard work


Question: <del> { lib, stdenv, fetchFromGitHub, pkg-config, ncurses, readline, conf ? null }: </del> <ins> { lib, stdenv, fetchFromGitHub, pkg-config, ncurses, readline , conf ? null, withIcons ? false, withNerdIcons ? false }: </ins> <del> with lib; </del> <ins> # Mutually exclusive options assert withIcons -> withNerdIcons == false; assert withNerdIcons -> withIcons == false; </ins> stdenv.mkDerivation rec { pname = "nnn";

It would be great to have option to fetch nnn plugins with nxpkgs or with additional package instead of manually fetching it like developer advise. And second is it possible to implement some option to include icons support from nerdfont to nnn binary file instead of recompiling it? Thanks.
I think this issue was closed preemptively by the line in the PR, there doesn't seem to be any way to include plugins as of now
nnn seems to expect plugins in . This might work better as a home-manager module, maybe with the plugins themselves as an output of nixpkgs. I might take a look at this next week.
I marked this as stale due to inactivity. →
I've recompiled nnn with icons, by using unstable branch and overriding nnn-package:
I marked this as stale due to inactivity. →


Question: <ins> { "owner": "simple-icons", "repo": "simple-icons", "rev": "bffc992b7d1365ee44b1683f8397e9f7a44d0c2c", "hash": "sha256-aqX6X/UsXXprWYU0xYK+wM9vWULYI8enCbVFebEM0yw=" } </ins>

Project description Ente's 2FA app. An end-to-end encrypted, cross platform and free app for storing your 2FA codes with cloud backups. Works offline. You can even use it without signing up for an account if you don't want the cloud backups or multi-device sync. Metadata homepage URL: source URL: license: AGPL-3.0 license platforms: linux, windows, android, ios, apple silicon macOS, web Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: # from upstream https://github.com/canonical/netplan/blob/ee0d5df7b1dfbc3197865f02c724204b955e0e58/rpm/netplan.spec#L81 sed -e "s/-Werror//g" -i Makefile <ins> substituteInPlace netplan/cli/utils.py  --replace-fail "/usr/libexec/netplan/generate" "${placeholder "out"}/lib/netplan/generate" </ins> ''; makeFlags = [

is failing with: Steps to reproduce the behavior: Result: It should work. N/A I need to use netplan locally to test generated configs, I don't actually need to apply them locally. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: mplleaflet = callPackage ../development/python-modules/mplleaflet { }; <ins> mpl-scatter-density = callPackage ../development/python-modules/mpl-scatter-density { }; </ins> mpmath = callPackage ../development/python-modules/mpmath { }; mpris-server = callPackage ../development/python-modules/mpris-server { };

Project description Glue is a python project to link visualizations of scientific datasets across many files. Click on the image for a quick demo: ! Metadata homepage URL: source URL: license: BSD Linux, BSD


Question: <del> --- old/build/pkgs/singular/spkg-install	2015-07-26 15:34:43.000000000 +0200 +++ new/build/pkgs/singular/spkg-install	2015-09-15 20:42:51.716505855 +0200 @@ -115,6 +115,11 @@ done } </del> <ins> --- old/build/pkgs/singular/spkg-install	2017-10-15 10:35:41.826540964 -0500 +++ new/build/pkgs/singular/spkg-install	2017-10-15 10:36:40.613743443 -0500 @@ -4,6 +4,9 @@ ## Singular ########################################### </ins> <del> +nix_nuke_bin_rm() +{ +    find . -exec sed -e 's@/bin/rm@rm@g' -i '{}' ';' +} </del> <ins> +find . -type f -exec sed -e 's@/bin/rm@rm@g' -i '{}' ';' +#echo '#!/usr/bin/env bashnIgnoring missing $1' > src/build-aux/missing </ins> + <del> remove_old_version() { rm -f "$SAGE_LOCAL"/bin/Singular* @@ -306,11 +311,11 @@ # Actually run all the functions defined above -for i in choose_patches apply_patches remove_old_version config  +for i in choose_patches apply_patches nix_nuke_bin_rm remove_old_version config  build_singular build_libsingular build_factory build_libfac  create_singular_script install_docs ; do echo "### Singular spkg-install: $i ###" -    cd "$SRC" && $i +    cd "$SRC" && pwd && $i if [ $? -ne 0 ]; then echo >&2 "Error building Singular (error in $i)." exit 1 </del> <ins> if [ -z "$SAGE_LOCAL" ]; then echo >&2 "Error: SAGE_LOCAL undefined -- exiting..." echo >&2 "Maybe run 'sage -sh'?" </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: <del> --- old/build/pkgs/singular/spkg-install	2015-07-26 15:34:43.000000000 +0200 +++ new/build/pkgs/singular/spkg-install	2015-09-15 20:42:51.716505855 +0200 @@ -115,6 +115,11 @@ done } </del> <ins> --- old/build/pkgs/singular/spkg-install	2017-10-15 10:35:41.826540964 -0500 +++ new/build/pkgs/singular/spkg-install	2017-10-15 10:36:40.613743443 -0500 @@ -4,6 +4,9 @@ ## Singular ########################################### </ins> <del> +nix_nuke_bin_rm() +{ +    find . -exec sed -e 's@/bin/rm@rm@g' -i '{}' ';' +} </del> <ins> +find . -type f -exec sed -e 's@/bin/rm@rm@g' -i '{}' ';' +#echo '#!/usr/bin/env bashnIgnoring missing $1' > src/build-aux/missing </ins> + <del> remove_old_version() { rm -f "$SAGE_LOCAL"/bin/Singular* @@ -306,11 +311,11 @@ # Actually run all the functions defined above -for i in choose_patches apply_patches remove_old_version config  +for i in choose_patches apply_patches nix_nuke_bin_rm remove_old_version config  build_singular build_libsingular build_factory build_libfac  create_singular_script install_docs ; do echo "### Singular spkg-install: $i ###" -    cd "$SRC" && $i +    cd "$SRC" && pwd && $i if [ $? -ne 0 ]; then echo >&2 "Error building Singular (error in $i)." exit 1 </del> <ins> if [ -z "$SAGE_LOCAL" ]; then echo >&2 "Error: SAGE_LOCAL undefined -- exiting..." echo >&2 "Maybe run 'sage -sh'?" </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: ./patches/widevine-79.patch ]; <del> postPatch = '' </del> <ins> postPatch = optionalString (versionRange "100" "101") '' base64 --decode ${webrtcWaylandScreenshareCoredumpFix} | patch -p1 -d third_party/webrtc '' + '' </ins> # remove unused third-party for lib in ${toString gnSystemLibraries}; do if [ -d "third_party/$lib" ]; then

Chromium coredumps on wayland/sway when trying to share a screen. Steps to reproduce the behavior: sway/wayland "" on "share screen" anywhere -Dump A selector for the screen to share should appear According chromium setting: According nixos configuration: Console output when the error occurs: Also this works fine with firefox-wayland and used to work with chromium. <!-- 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.
Could be related to as it also states
Did screen sharing work before / is that crash (segmentation fault) new? And do you know since which version it stopped working? So far screen sharing did never work reliably and there have been frequent regressions: (I've fixed it twice on my test setup but I've given up since then). We might want to close this issue in favor of to keep the discussion in one place.
For me, screenshare works on Chromium v99, and stopped working after update to v100
For me it also worked in the past without issues. This is new and this is chrome core-dumping. This is a different issue. If screen sharing did not work in the past, it just did not work. It did not cause an out of bounds read or crash of the browser. Please don't close this issue.
Sure, we can leave it open. We should mention it in the other issue though (I just did that) for better visibility. Now we need someone with time and motivation to handle this issue (analyzing the issue, searching for upstream issues, etc. and eventually someone needs to submit a fix).
Since this is NixOS and we have the boon of input-reproducibility and a binary cache, could you post: the nixpkgs commit you are on the nix store path of your chromium binary This will make it even easier for others to reproduce. You may also be able to get the stack trace with GDB using , use , make the segfault happen, and use in GDB.


Question: ./patches/widevine-79.patch ]; <del> postPatch = '' </del> <ins> postPatch = optionalString (versionRange "100" "101") '' base64 --decode ${webrtcWaylandScreenshareCoredumpFix} | patch -p1 -d third_party/webrtc '' + '' </ins> # remove unused third-party for lib in ${toString gnSystemLibraries}; do if [ -d "third_party/$lib" ]; then

nixpkgs: /nix/store/07346c7jv5wnwg30r5dvmlgqbk52hinz-chromium-100.0.4896.60/bin/chromium
Regarding gdb: ` How do I get gdb on the actual executable but keep the env vars of the shell script wrapper?
Now edit , replacing like this: Then terminate all chromium instances (to avoid joining existing instances), and run .
Thank you for the detailed instructions!
Looks like it should be fixed in m101
I tried to build chromiumDev(102) or chrimiumBeta (101) - but both failed with errors related to:
This patch may be useful: https://webrtc-
I'm a week old to nix, but trying to figure out a way to patch it. It seems it needs a special flag due to it's location:
building chrome is an undertaking not to be embarked on lightly. you can install the chrome dev or beta channel package. On my up-to-date, flakes-enabled nixos-unstable: The issue seems fixed there. There are builds of chromium upstream here: (under other), but I'm not sure if there is a nix derivation for them.
I've opened for a quick and dirty fix - the code isn't pretty but should do the job (I wish would support Base64 patches or even better: Gerrit and gitiles would support fetching patches using a sane format like basically any other web VCS frontend does...). Anyway, I'll check if the VM test passes (although that patch is so trivial that it should be unnecessary) and can merge the fix tomorrow.
I love the name and thanks a lot for your time & effort!