Question: <ins> { lib, stdenvNoCC, fetchFromGitHub, glib, # These loosen security a bit, so we don't install them by default. See also: # https://github.com/hardpixel/systemd-manager?tab=readme-ov-file#without-password-prompt allowPolkitPolicy ? "none", config, systemd ? config.systemd.package, }: assert lib.elem allowPolkitPolicy [ "none" "pkexec" "systemctl" ]; stdenvNoCC.mkDerivation rec { pname = "gnome-shell-extension-systemd-manager"; version = "16"; # Upstream doesn't post new versions in extensions.gnome.org anymore, see also: # https://github.com/hardpixel/systemd-manager/issues/19 src = fetchFromGitHub { owner = "hardpixel"; repo = "systemd-manager"; rev = "v${version}"; hash = "sha256-JecSIRj582jJWdrCQYBWFRkIhosxRhD3BxSAy8/0nVw="; }; nativeBuildInputs = [ glib ]; postInstall = '' rm systemd-manager@hardpixel.eu/schemas/gschemas.compiled glib-compile-schemas systemd-manager@hardpixel.eu/schemas mkdir -p $out/share/gnome-shell/extensions mv systemd-manager@hardpixel.eu $out/share/gnome-shell/extensions '' + lib.optionalString (allowPolkitPolicy == "pkexec") '' local bn=org.freedesktop.policykit.pkexec.systemctl.policy mkdir -p $out/share/polkit-1/actions substitute systemd-policies/$bn $out/share/polkit-1/actions/$bn  --replace-fail /usr/bin/systemctl ${lib.getBin systemd}/bin/systemctl '' + lib.optionalString (allowPolkitPolicy == "systemctl") '' install -Dm0644  systemd-policies/10-service_status.rules  $out/share/polkit-1/rules.d/10-gnome-extension-systemd-manager.rules ''; passthru = { extensionUuid = "systemd-manager@hardpixel.eu"; extensionPortalSlug = "systemd-manager"; }; meta = with lib; { description = "GNOME Shell extension to manage systemd services"; homepage = "https://github.com/hardpixel/systemd-manager"; license = licenses.gpl3Only; maintainers = with maintainers; [ linsui doronbehar ]; }; } </ins>

This needs to be done by someone and they will become the maintainer. you use this hack you will have to update the for NixOS whenever the developers of release a new update.
Upstream devs released version 16. Whoo hooo! Here is the .nix to make it work on your local machine. Again, this is not in the main nixpkgs repo. You will have to use this code and follow my "hack"above to get it to run in your local nix install. Thanks again to for the original code.


Question: githubId = 1891350; name = "Michael Raskin"; }; <ins> raspher = { email = "raspher@protonmail.com"; github = "raspher"; githubId = 23345803; name = "Szymon Scholz"; }; </ins> ratcornu = { email = "ratcornu@skaven.org"; github = "RatCornu";

Project description An end-to-end encrypted, peer-to-peer file storage, sharing and communication network. It's written in Java and uses IPFS. A bit similar to Nextcloud. Metadata homepage URL: source URL: license: AGPL3 platforms: linux (JVM)
Related:
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 .
Still important
I marked this as stale due to inactivity. →
Still important
I marked this as stale due to inactivity. →
I've a working package of peergos. after some testing i've experienced it a little buggy, so i don't want to push it into release. Let's see what i can do as it's my first package. The example bug: after i've created task, clicking "tasks" from left menu forces me to create new task. However thecreated task is visible in my drive.
Thanks!


Question: <del> { lib, ocamlPackages, fetchFromGitHub, python3, dune_3, makeWrapper, poppler_utils }: </del> <ins> { lib, ocamlPackages, fetchFromGitHub, python3, dune_3, makeWrapper, poppler_utils, fzf }: </ins> ocamlPackages.buildDunePackage rec { pname = "docfd";

needs in it's path to be able to use the fuzzy file picker, e.g. produces file picker should open <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: cfg = config.environment; <del> pamProfiles = map (replaceStrings ["$HOME" "$USER"] ["@{HOME}" "@{PAM_USER}"]) cfg.profiles; </del> in {

Describe the bug When I did we assumed that variables like and would be replaced with or . This is not true and in the pam configuration we have variables. cc


Question: <ins> From d3cb66e4751fcbd581b81a14a973de2d78fc02ad Mon Sep 17 00:00:00 2001 From: Liu Hao <lh_mouse@126.com> Date: Mon, 18 Apr 2016 11:50:55 +0800 Subject: [PATCH] Added 'mcf' thread model support from mcfgthread. Signed-off-by: Liu Hao <lh_mouse@126.com> --- config/gthr.m4                          |  1 + gcc/config.gcc                          |  3 +++ gcc/config/i386/mingw-mcfgthread.h      |  1 + gcc/config/i386/mingw-w64.h             |  2 +- gcc/config/i386/mingw32.h               | 11 ++++++++++- gcc/configure                           |  2 +- gcc/configure.ac                        |  2 +- libatomic/configure.tgt                 |  2 +- libgcc/config.host                      |  6 ++++++ libgcc/config/i386/gthr-mcf.h           |  1 + libgcc/config/i386/t-mingw-mcfgthread   |  2 ++ libgcc/configure                        |  1 + libstdc++-v3/configure                  |  1 + libstdc++-v3/libsupc++/atexit_thread.cc | 18 ++++++++++++++++++ libstdc++-v3/libsupc++/guard.cc         | 23 +++++++++++++++++++++++ 15 files changed, 71 insertions(+), 5 deletions(-) create mode 100644 gcc/config/i386/mingw-mcfgthread.h create mode 100644 libgcc/config/i386/gthr-mcf.h create mode 100644 libgcc/config/i386/t-mingw-mcfgthread diff --git a/config/gthr.m4 b/config/gthr.m4 index 7b29f1f3327..82e21fe1709 100644 --- a/config/gthr.m4 +++ b/config/gthr.m4 @@ -21,6 +21,7 @@ case $1 in tpf)	thread_header=config/s390/gthr-tpf.h ;; vxworks)	thread_header=config/gthr-vxworks.h ;; win32)	thread_header=config/i386/gthr-win32.h ;; +    mcf)	thread_header=config/i386/gthr-mcf.h ;; esac AC_SUBST(thread_header) ]) diff --git a/gcc/config.gcc b/gcc/config.gcc index 8f91197f34e..59db37cac04 100644 --- a/gcc/config.gcc +++ b/gcc/config.gcc @@ -1719,6 +1719,9 @@ i[34567]86-*-mingw* | x86_64-*-mingw*) if test x$enable_threads = xposix ; then tm_file="${tm_file} i386/mingw-pthread.h" fi +	if test x$enable_threads = xmcf ; then +		tm_file="${tm_file} i386/mingw-mcfgthread.h" +	fi tm_file="${tm_file} i386/mingw32.h" # This makes the logic if mingw's or the w64 feature set has to be used case ${target} in diff --git a/gcc/config/i386/mingw-mcfgthread.h b/gcc/config/i386/mingw-mcfgthread.h new file mode 100644 index 00000000000..ec381a7798f --- /dev/null +++ b/gcc/config/i386/mingw-mcfgthread.h @@ -0,0 +1 @@ +#define TARGET_USE_MCFGTHREAD 1 diff --git a/gcc/config/i386/mingw-w64.h b/gcc/config/i386/mingw-w64.h index 270ec0dd037..88966f79695 100644 --- a/gcc/config/i386/mingw-w64.h +++ b/gcc/config/i386/mingw-w64.h @@ -48,7 +48,7 @@ along with GCC; see the file COPYING3.  If not see "%{mwindows:-lgdi32 -lcomdlg32} "  "%{fvtable-verify=preinit:-lvtv -lpsapi;  fvtable-verify=std:-lvtv -lpsapi} "  -		 "-ladvapi32 -lshell32 -luser32 -lkernel32" +		 LIB_MCFGTHREAD "-ladvapi32 -lshell32 -luser32 -lkernel32" #undef SPEC_32 #undef SPEC_64 diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h index e5f014cb473..989cfbe894e 100644 --- a/gcc/config/i386/mingw32.h +++ b/gcc/config/i386/mingw32.h @@ -32,6 +32,14 @@ along with GCC; see the file COPYING3.  If not see | MASK_STACK_PROBE | MASK_ALIGN_DOUBLE  | MASK_MS_BITFIELD_LAYOUT) +#ifndef TARGET_USE_MCFGTHREAD +#define CPP_MCFGTHREAD()  ((void)0) +#define LIB_MCFGTHREAD     "" +#else +#define CPP_MCFGTHREAD()  (builtin_define("__USING_MCFGTHREAD__")) +#define LIB_MCFGTHREAD     " -lmcfgthread " +#endif + /* See i386/crtdll.h for an alternative definition. _INTEGRAL_MAX_BITS is for compatibility with native compiler.  */ #define EXTRA_OS_CPP_BUILTINS()					 @@ -50,6 +58,7 @@ along with GCC; see the file COPYING3.  If not see builtin_define_std ("WIN64");				 builtin_define ("_WIN64");				 }							 +	CPP_MCFGTHREAD();	 }								 while (0) @@ -93,7 +102,7 @@ along with GCC; see the file COPYING3.  If not see "%{mwindows:-lgdi32 -lcomdlg32} "  "%{fvtable-verify=preinit:-lvtv -lpsapi;  fvtable-verify=std:-lvtv -lpsapi} "  -                 "-ladvapi32 -lshell32 -luser32 -lkernel32" +                 LIB_MCFGTHREAD "-ladvapi32 -lshell32 -luser32 -lkernel32" /* Weak symbols do not get resolved if using a Windows dll import lib. Make the unwind registration references strong undefs.  */ diff --git a/gcc/configure b/gcc/configure index ea73b151a4e..317200e5620 100755 --- a/gcc/configure +++ b/gcc/configure @@ -11681,7 +11681,7 @@ case ${enable_threads} in target_thread_file='single' ;; aix | dce | lynx | mipssde | posix | rtems |  -  single | tpf | vxworks | win32) +  single | tpf | vxworks | win32 | mcf) target_thread_file=${enable_threads} ;; *) diff --git a/gcc/configure.ac b/gcc/configure.ac index 9d4c792a33f..d51899a5676 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1612,7 +1612,7 @@ case ${enable_threads} in target_thread_file='single' ;; aix | dce | lynx | mipssde | posix | rtems |  -  single | tpf | vxworks | win32) +  single | tpf | vxworks | win32 | mcf) target_thread_file=${enable_threads} ;; *) diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt index b8af3ab2546..73248438a8c 100644 --- a/libatomic/configure.tgt +++ b/libatomic/configure.tgt @@ -125,7 +125,7 @@ case "${target}" in *-*-mingw*) # OS support for atomic primitives. case ${target_thread_file} in -          win32) +          win32 | mcf) config_path="${config_path} mingw" ;; posix) diff --git a/libgcc/config.host b/libgcc/config.host index b279a6458f9..20d22f585da 100644 --- a/libgcc/config.host +++ b/libgcc/config.host @@ -710,6 +710,9 @@ i[34567]86-*-mingw*) posix) tmake_file="i386/t-mingw-pthread $tmake_file" ;; +	  mcf) +	    tmake_file="i386/t-mingw-mcfgthread $tmake_file" +	    ;; esac # This has to match the logic for DWARF2_UNWIND_INFO in gcc/config/i386/cygming.h if test x$ac_cv_sjlj_exceptions = xyes; then @@ -734,6 +737,9 @@ x86_64-*-mingw*) posix) tmake_file="i386/t-mingw-pthread $tmake_file" ;; +	  mcf) +	    tmake_file="i386/t-mingw-mcfgthread $tmake_file" +	    ;; esac # This has to match the logic for DWARF2_UNWIND_INFO in gcc/config/i386/cygming.h if test x$ac_cv_sjlj_exceptions = xyes; then diff --git a/libgcc/config/i386/gthr-mcf.h b/libgcc/config/i386/gthr-mcf.h new file mode 100644 index 00000000000..5ea2908361f --- /dev/null +++ b/libgcc/config/i386/gthr-mcf.h @@ -0,0 +1 @@ +#include <mcfgthread/gthread.h> diff --git a/libgcc/config/i386/t-mingw-mcfgthread b/libgcc/config/i386/t-mingw-mcfgthread new file mode 100644 index 00000000000..4b9b10e32d6 --- /dev/null +++ b/libgcc/config/i386/t-mingw-mcfgthread @@ -0,0 +1,2 @@ +SHLIB_PTHREAD_CFLAG = +SHLIB_PTHREAD_LDFLAG = -lmcfgthread diff --git a/libgcc/configure b/libgcc/configure index 45c459788c3..8fc569ef16e 100644 --- a/libgcc/configure +++ b/libgcc/configure @@ -5086,6 +5086,7 @@ case $target_thread_file in tpf)	thread_header=config/s390/gthr-tpf.h ;; vxworks)	thread_header=config/gthr-vxworks.h ;; win32)	thread_header=config/i386/gthr-win32.h ;; +    mcf)	thread_header=config/i386/gthr-mcf.h ;; esac diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure index 2406cb9d946..50e7e4ced89 100755 --- a/libstdc++-v3/configure +++ b/libstdc++-v3/configure @@ -15182,6 +15182,7 @@ case $target_thread_file in tpf)	thread_header=config/s390/gthr-tpf.h ;; vxworks)	thread_header=config/gthr-vxworks.h ;; win32)	thread_header=config/i386/gthr-win32.h ;; +    mcf)	thread_header=config/i386/gthr-mcf.h ;; esac diff --git a/libstdc++-v3/libsupc++/atexit_thread.cc b/libstdc++-v3/libsupc++/atexit_thread.cc index 923a0707556..a55d85aad2d 100644 --- a/libstdc++-v3/libsupc++/atexit_thread.cc +++ b/libstdc++-v3/libsupc++/atexit_thread.cc @@ -25,6 +25,22 @@ #include <cstdlib> #include <new> #include "bits/gthr.h" + +#ifdef __USING_MCFGTHREAD__ + +#include <mcfgthread/gthread.h> + +extern "C" int +__cxxabiv1::__cxa_thread_atexit (void (*dtor)(void *), +				 void *obj, void *dso_handle) +  _GLIBCXX_NOTHROW +{ +  return ::_MCFCRT_AtThreadExit((void (*)(_MCFCRT_STD intptr_t))dtor, (_MCFCRT_STD intptr_t)obj) ? 0 : -1; +  (void)dso_handle; +} + +#else // __USING_MCFGTHREAD__ + #ifdef _GLIBCXX_THREAD_ATEXIT_WIN32 #define WIN32_LEAN_AND_MEAN #include <windows.h> @@ -167,3 +183,5 @@ __cxxabiv1::__cxa_thread_atexit (void (*dtor)(void *), void *obj, void */*dso_ha } #endif /* _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL */ + +#endif // __USING_MCFGTHREAD__ diff --git a/libstdc++-v3/libsupc++/guard.cc b/libstdc++-v3/libsupc++/guard.cc index 19953bc52f0..72fd5f26d5b 100644 --- a/libstdc++-v3/libsupc++/guard.cc +++ b/libstdc++-v3/libsupc++/guard.cc @@ -28,6 +28,27 @@ #include <cxxabi.h> #include <exception> #include <new> + +#ifdef __USING_MCFGTHREAD__ + +#include <mcfgthread/gthread.h> + +namespace __cxxabiv1 { + +extern "C" int __cxa_guard_acquire(__guard *g){ +	return ::_MCFCRT_WaitForOnceFlagForever((::_MCFCRT_OnceFlag *)g) == ::_MCFCRT_kOnceResultInitial; +} +extern "C" void __cxa_guard_abort(__guard *g) throw() { +	::_MCFCRT_SignalOnceFlagAsAborted((::_MCFCRT_OnceFlag *)g); +} +extern "C" void __cxa_guard_release(__guard *g) throw() { +	::_MCFCRT_SignalOnceFlagAsFinished((::_MCFCRT_OnceFlag *)g); +} + +} + +#else // __USING_MCFGTHREAD__ + #include <ext/atomicity.h> #include <ext/concurrence.h> #include <bits/atomic_lockfree_defines.h> @@ -425,3 +446,5 @@ namespace __cxxabiv1 #endif } } + +#endif -- 2.12.1 </ins>

Describe the bug is when building for MinGW, however an equivalent GCC 10 patch file doesn't exist. I tried looking for a GCC 10 patch on the master branch of , but the folder that contained the patches no longer exists. GCC9 is still currently the default on master, but this will break everything under MinGW the next time staging-next is merged to master. See Support for was originally in To Reproduce Steps to reproduce the behavior: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
It has been moved to to upstream migration. Neither of these repos is stable; their master branches are constantly rebased on upstream and force-pushed.


Question: <ins> { lib, buildPythonPackage, fetchPypi, pythonOlder }: buildPythonPackage rec { pname = "pathvalidate"; version = "2.4.1"; disabled = pythonOlder "3.5"; src = fetchPypi { inherit pname version; sha256 = "sha256-PJvZTH7CPpz7IR/741audfl51sCZosdF7pSQ9STzJGg="; }; # Requires `pytest-md-report`, causing infinite recursion. doCheck = false; pythonImportsCheck = [ "pathvalidate" ]; meta = with lib; { description = "A Python library to sanitize/validate a string such as filenames/file-paths/etc"; homepage = "https://github.com/thombashi/pathvalidate"; license = licenses.mit; maintainers = with maintainers; [ oxalica ]; }; } </ins>

Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. 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 Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:


Question: burp = callPackage ../tools/backup/burp { }; <del> buku = callPackage ../applications/misc/buku { }; </del> <ins> buku = callPackage ../applications/misc/buku { python3 = python36; # due to #52766 }; </ins> byzanz = callPackage ../applications/video/byzanz {};

tests pass, while tests fail with: Official Hydra sees the same thing: with their Travis setup. (That is a build of a recent commit, but I still see the same failures after pointing at a checkout of ) Does anyone have any ideas? With nixpkgs master,
See scrapinghub/dateparser, scrapinghub/dateparser and scrapinghub/dateparser.
As long as this problem remains, the best thing to do is using for affected application. Switching to should be done in commits that don't change anything else and that reference this issue in their commit message so that they can easily be reverted. Simply skipping the tests does not make much sense since these are real incompatibilities.


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


Question: ++ lib.optional (enableStatic && enableShared) "static"; buildInputs = lib.optional pythonSupport python <ins> ++ lib.optional (pythonSupport && python?isPy2 && python.isPy2) gettext </ins> ++ lib.optional (pythonSupport && python?isPy3 && python.isPy3) ncurses # Libxml2 has an optional dependency on liblzma.  However, on impure # platforms, it may end up using that from /usr/lib, and thus lack a

Unable to build libxml2 Repro: nix-env -i libxml2 make[4]: Entering directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' CC CC libxml2- CC libxml.c:1649:43: warning: passing 'unsigned char ' to parameter of type 'const char ' converts between pointers to integer types with different sign [-Wpointer-sign] message = libxmlcharPtrConstWrap(ptr); ^~~ ./libxmlwrap.h:240:48: note: passing argument to parameter 'str' here PyObject libxmlcharPtrConstWrap(const char str); ^ 1 warning generated.


Question: ++ lib.optional (enableStatic && enableShared) "static"; buildInputs = lib.optional pythonSupport python <ins> ++ lib.optional (pythonSupport && python?isPy2 && python.isPy2) gettext </ins> ++ lib.optional (pythonSupport && python?isPy3 && python.isPy3) ncurses # Libxml2 has an optional dependency on liblzma.  However, on impure # platforms, it may end up using that from /usr/lib, and thus lack a

CCLD ld: library not found for -lintl clang-7: error: linker command failed with exit code 1 (use -v to see invocation) make[4]: [Makefile:600: ] Error 1 make[4]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make[3]: [Makefile:694: all-recursive] Error 1 make[3]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make[2]: [Makefile:528: all] Error 2 make[2]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make[1]: [Makefile:1479: all-recursive] Error 1 make[1]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make: [Makefile:893: all] Error 2 builder for '/nix/store/xcqdl8cfjjbjvh7g9ka0ip3r4awy80a8-libxml2-' failed with exit code 2 error: build of '/nix/store/xcqdl8cfjjbjvh7g9ka0ip3r4awy80a8-libxml2-' failed Metadata* system: host os: multi-user?: sandbox: version: channels(swarnpriya): nixpkgs:
Disclaimer: I barely know what I'm doing. I tried adding as a build input to libxml2. That got this error:
I've been getting this as well, since . Any clue? I think this sort of thing has happened before, but I don't recall the details.
I thought somebody else already fixed this after some discussion no irc. My proposal was essentially the patch above but guarded for python2 only.


Question: <ins> { stdenv, fetchurl, ncurses }: stdenv.mkDerivation { name = "watch-0.2.0"; src = fetchurl { url = http://procps.sourceforge.net/procps-3.2.8.tar.gz; sha256 = "0d8mki0q4yamnkk4533kx8mc0jd879573srxhg6r2fs3lkc6iv8i"; }; buildInputs = [ ncurses ]; makeFlags = "watch usrbin_execdir=$(out)/bin" + (if stdenv.isDarwin then " PKG_LDFLAGS=" else ""); enableParallelBuilding = true; crossAttrs = { CC = stdenv.cross.config + "-gcc"; }; installPhase = "mkdir $out; mkdir -p $out/bin; cp -p watch $out/bin"; meta = { homepage = http://sourceforge.net/projects/procps/; description = "Utility for watch the output of a given command at intervals"; platforms = stdenv.lib.platforms.unix; }; } </ins>

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


Question: <del> { lib, stdenv, fetchurl, autoreconfHook, pkg-config, fftw }: </del> <ins> { lib , stdenv , fetchurl , autoreconfHook , pkg-config , fftw , withFftw3 ? true }: </ins> stdenv.mkDerivation rec { pname = "speexdsp";

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


Question: }; }; <ins> imperative = { ... }: { imports = [ ../modules/profiles/minimal.nix ]; # add a virtual wlan interface boot.kernelModules = [ "mac80211_hwsim" ]; # wireless client networking.wireless = { enable = lib.mkOverride 0 true; userControlled.enable = true; allowAuxiliaryImperativeNetworks = true; interfaces = [ "wlan1" ]; }; }; </ins> # Test connecting to the SAE-only hotspot using SAE machineSae = machineWithHostapd { networking.wireless = {

After installing a fresh system with the following configuration: the file is not created, hence wpasupplicant fails to start with the following error: nixpkgs
I don't know the logic of , but I think you're supposed to provide the file yourself. I guess it could be ed if wpa_supplicant fails without one.
You can do
That probably wouldn't work due to permissions. EDIT: wpa_supplicant is still running as root, so it should work.
Fixed in


Question: diff --git a/src/dist/component/package.rs b/src/dist/component/package.rs <del> index 4b432785..fa45e87e 100644 </del> <ins> index 3beddf54..0f859b8d 100644 </ins> --- a/src/dist/component/package.rs +++ b/src/dist/component/package.rs <del> @@ -109,10 +109,11 @@ impl Package for DirectoryPackage { match &*part.0 { "file" => { if self.copy { -                        builder.copy_file(path.clone(), &src_path)? +                        builder.copy_file(path.clone(), &src_path)?; </del> <ins> @@ -113,6 +113,7 @@ impl Package for DirectoryPackage { </ins> } else { <del> -                        builder.move_file(path.clone(), &src_path)? +                        builder.move_file(path.clone(), &src_path)?; </del> <ins> builder.move_file(path.clone(), &src_path)? </ins> } +                    nix_patchelf_if_needed(&target.prefix().path().join(path.clone()), &src_path) } "dir" => { if self.copy { <del> @@ -135,6 +136,22 @@ impl Package for DirectoryPackage { </del> <ins> @@ -135,6 +136,29 @@ impl Package for DirectoryPackage { </ins> } } +fn nix_patchelf_if_needed(dest_path: &Path, src_path: &Path) { <del> +    let is_bin = if let Some(p) = src_path.parent() { +        p.ends_with("bin") </del> <ins> +    let (is_bin, is_lib) = if let Some(p) = src_path.parent() { +        (p.ends_with("bin"), p.ends_with("lib")) </ins> +    } else { <del> +        false </del> <ins> +        (false, false) </ins> +    }; + +    if is_bin {

Describe the bug As of rust nightly 2020-06-22, Rust nightly cannot find This issue is not present in Rust nightly 2020-06-21. To Reproduce Steps to reproduce the behavior: Expected behavior rustc works Additional context This also happens with rust nightly from Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jade): nixpkgs: Maintainer information:
We are currently using in internally to set the elf interpreter. Looks like we need to extend this to also extend the RPATH to add zlib. If someone makes a PR, I will review it! Not sure when I would get to implement that myself.
Here is where we add :
I'm working on a patch for this. This is definitely the issue, just need to find the right way to extend the RPATH. I have something replacing it with a path containing zlib, but that overwrites the existing , which breaks it. I would like to verify what is setting there but hardcoding it should provide an early fix
Extending the RPATH seems not to have worked
I'm investigating patching the files in lib This issue may have been introduced by rust-lang/rust so it's likely the new zlib dependency shows up in the LLVM libraries


Question: chmod +x $out/bin/igv chmod +x $out/bin/igvtools ''; <ins> nativeBuildInputs = [ wrapGAppsHook ]; </ins> meta = with lib; { homepage = "https://www.broadinstitute.org/igv/";

The IGV package freezes and crashed when a file dialog should open (open file, save as, etc.). Steps to reproduce the behavior: igv: igv "File" -"Load from File.." application crashes The file dialog should open and allow me to open a file. If I open igv through the terminal, then this error is shown: This error is the same as previously reported issues for other application, e.g. I'll shortly open a PR with the same fix. I'll rather do that in the PR with the fix. Please run and paste the result. NA


Question: <ins> { lib, buildPythonPackage, fetchPypi, pefile, pillow}: buildPythonPackage rec { pname = "icoextract"; version = "0.1.4"; src = fetchPypi { inherit pname version; extension = "tar.gz"; sha256 = "sha256-x0GEV0PUbkAzoUJgAqup9bHd7iYttGyzIZNdo8KsFyo="; }; propagatedBuildInputs = [ pefile pillow ]; # tests expect mingw and multiarch doCheck = false; pythonImportsCheck = [ "icoextract" ]; meta = with lib; { description = "Extract icons from Windows PE files"; homepage = "https://github.com/jlu5/icoextract"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

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


Question: <ins> { lib, buildPythonPackage, fetchPypi, pefile, pillow}: buildPythonPackage rec { pname = "icoextract"; version = "0.1.4"; src = fetchPypi { inherit pname version; extension = "tar.gz"; sha256 = "sha256-x0GEV0PUbkAzoUJgAqup9bHd7iYttGyzIZNdo8KsFyo="; }; propagatedBuildInputs = [ pefile pillow ]; # tests expect mingw and multiarch doCheck = false; pythonImportsCheck = [ "icoextract" ]; meta = with lib; { description = "Extract icons from Windows PE files"; homepage = "https://github.com/jlu5/icoextract"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: bottles <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2022.5.28-trento-3 desired version: 2022.7.14-brescia-1 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
While automatic update using was removed by in you need to wait while we will "get auto updates from r-rynatm"
That not true. I removed the over complicated updater in which wasn't necessary at all. Since r-ryantm also uses nix-update there was also no need to replace it. That's wrong. You can always create an update PR yourself by running ` or by manually update the package and create a PR with that. r-ryantm goes through all packages so it can sometimes take a few days until the update PR is created. Also nix-update is very lightweight with minimal dependencies, so there is not really a reason to not use it. It also does not require any kind of token or authentication.
Bottles the version released after the one currently present in nixpkgs, was released on June 13. Over one month has passed, so something about the auto-updater isn't working.
The latest r-ryantm log is here . Not sure why that is not working like it should.
I guess a update script is needed for this case :disappointed: Since the package is using , it HAS a fallback update script , so nixpkgs-update is no longer trying to figure out the latest version itself but just run the script.


Question: <ins> { lib, buildPythonPackage, fetchPypi, pefile, pillow}: buildPythonPackage rec { pname = "icoextract"; version = "0.1.4"; src = fetchPypi { inherit pname version; extension = "tar.gz"; sha256 = "sha256-x0GEV0PUbkAzoUJgAqup9bHd7iYttGyzIZNdo8KsFyo="; }; propagatedBuildInputs = [ pefile pillow ]; # tests expect mingw and multiarch doCheck = false; pythonImportsCheck = [ "icoextract" ]; meta = with lib; { description = "Extract icons from Windows PE files"; homepage = "https://github.com/jlu5/icoextract"; license = licenses.mit; maintainers = with maintainers; [ bryanasdev000 ]; }; } </ins>

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


Question: buildPythonPackage rec { pname = "Shapely"; <del> version = "1.8.2"; </del> <ins> version = "1.8.4"; </ins> disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> sha256 = "sha256-Vyr51QBv1eMhPjfuVIkSsDQfsmck1tyKTjlQwQGX67Y="; </del> <ins> sha256 = "sha256-oZXlHKr6IYKR8suqP+9p/TNTyT7EtlsqRyLEz0DDGYw="; </ins> }; nativeBuildInputs = [

Add any other context about the problem here. Please run and paste the result. repro'd on commit id
backtrace: <details<summaryBacktrace from lldb</summary</details
shapely 1.8.4 with the fix is now in pypi, I saw you wanted to upgrade it, did you get around to do it?
thanks for the reminder, committed it


Question: "ftp://ftp.freedesktop.org/pub/mesa/${version}/mesa-${version}.tar.xz" "ftp://ftp.freedesktop.org/pub/mesa/older-versions/${branch}.x/${version}/mesa-${version}.tar.xz" ]; <del> sha256 = "1fqj2xhhd1ary0pfg31jq6fqcnd6qgyrw1445nmz554k8n2ck7rp"; </del> <ins> sha256 = "0awiyvicvcn3b18x0vx5ik3ly0k3k51ivz2ljj8pnx6ms95nyp2n"; </ins> }; prePatch = "patchShebangs .";

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


Question: --replace "include (''${CMAKE_CURRENT_SOURCE_DIR}/googletest.cmake)" "" --replace "include(GoogleTest)" "find_package(GTest REQUIRED)" <del> cat << EOF > python/triton/common/build.py </del> <ins> cat << EOF >> python/triton/common/build.py </ins> def libcuda_dirs(): return [ "${addDriverRunpath.driverLink}/lib" ] EOF

Steps to reproduce the behavior: Commit seems likely to have broken the build for bitsandbytes. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I suspect the above output is related to that commit modifies or creates the module referenced above. I'm rebuilding setting the to and to to see if having dummy definitions solves the problem. Unfortunately it's slow going as it requires a full pytorch rebuild to see if it repaired bitsandbytes.
the trivial fix proposed above appears to resolve the build. Not sure if this would have ramifications elsewhere in the tree. Happy to PR the change if others want to help kick the tires
Oh!!! was mean to be a not ... how on earth did this even pass the tests (i.e. I only meant to abuse python's imperative-ness to override and keep all other symbols intact...)
a PR would be very welcome
looks like your original idea should also work, and be less broken in mysterious ways, I can do a quick PR after I make sure it works on my end.


Question: # does not contain any tests doCheck = false; <ins> enableParallelBuilding = true; </ins> pythonImportsCheck = [ "grpc" ]; meta = with lib; {

Building uses more () threads than it should (i.e. 2 if / ). Steps to reproduce the behavior: as the build will use way more than 2 cores. Build should honour properly. This was with . This does not in fact use just 1 thread. :smilingfacewith_tear:. ! Happens on master () and 22.11.
I don't have any time planned to fix this but if you figure it out please send a PR.


Question: # Add gio to PATH so that moving files to the trash works when not using a desktop environment --prefix PATH : ${glib.bin}/bin --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--enable-features=UseOzonePlatform --ozone-platform=wayland}}" <ins> --add-flags ${lib.escapeShellArg commandLineArgs} </ins> ) '';

For Chromium, there's a convenient way to define custom flags through . However, there doesn't seem to be a similar option for . I tried setting to "--touch-events", but touchscreen scrolling is not enabled when starting VSCode from desktop launcher, while running in console works as expected. Steps to reproduce the behavior: to "--touch-events" VSCode from desktop launcher on the editor area through touchscreen The editor should scroll as I drag. system: host os: multi-user?: sandbox: version: channels(yes): channels(root): nixpkgs:


Question: meson ninja pkg-config <del> python3 </del> wrapGAppsHook4 ] ++ (with rustPlatform; [ cargoSetupHook

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


Question: SystemCallFilter = [ "@system-service" <del> "~@resources" </del> "~@privileged" ]; SystemCallArchitectures = "native";

Gotenberg crashes immediately on startup Enter the following into your nix config: It not crashing but starting up normally ! Gotenberg was to be used in conjunction with paperless-ngx. is the entire file Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are there any more logs from the Gotenberg service? Or is the coredump all that's available?
Sadly that is all. The service log literally doesn't say anything. There you only see that the service started and immediately exited. This log i got by typing
Sorry for the slow response, but I looked at this and figured out the issue. Could you test and see if it fixes your issue?


Question: <del> { lib, buildGoModule, fetchFromGitHub, installShellFiles }: buildGoModule rec { pname = "pritunl-client"; </del> <ins> { lib , stdenv , fetchFromGitHub , runtimeShell , runCommand , makeWrapper , installShellFiles , buildGoModule , coreutils , which , gnugrep , gnused , openresolv , systemd , iproute2 , openvpn , electron }: let </ins> version = "1.3.3584.5"; src = fetchFromGitHub { owner = "pritunl"; repo = "pritunl-client-electron";

Project description <!-- Describe the project a little: --This is a electron-based app client for Pritunl server Metadata homepage URL: source URL: license: Non-Commercial platforms: linux
Pending review in


Question: #!/usr/bin/env nix-shell <del> #! nix-shell -I nixpkgs=../../../.. -i python3 -p bundix bundler nix-update nix nix-universal-prefetch python3 python3Packages.requests python3Packages.click python3Packages.click-log python3Packages.packaging prefetch-yarn-deps git </del> <ins> #! nix-shell -I nixpkgs=../../../.. -i python3 -p bundix bundler nix-update nix python3 python3Packages.requests python3Packages.click python3Packages.click-log python3Packages.packaging prefetch-yarn-deps git </ins> import click import click_log

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: julia_11 = throw "julia_11 has been deprecated in favor of the latest stable version"; # Added 2020-09-15 julia_13 = throw "julia_13 has been deprecated in favor of the latest stable version"; # Added 2021-03-13 julia_10-bin = throw "julia_10-bin has been deprecated in favor of the latest LTS version"; # Added 2021-12-02 <ins> julia_17-bin = throw "julia_17-bin has been deprecated in favor of the latest stable version"; # Added 2022-09-04 </ins> json_glib = throw "'json_glib' has been renamed to/replaced by 'json-glib'"; # Converted to throw 2022-02-22 jvmci8 = throw "graalvm8 and its tools were deprecated in favor of graalvm8-ce"; # Added 2021-10-15

<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.7.3 desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
I started preparing the update in . Cc:


Question: # Allow multiple colon-separated authorized keys files to be # specified in the file= option. ./multiple-key-files.patch <ins> ./edcsa-crash-fix.patch </ins> ]; configureFlags = [

Describe the bug After upgrading to NixOS 20.03, sudo often (but not always) segfaults: From the logs: Disabling appears to have made this problem to away, so the problem may be in . Metadata NixOS 20.03..
Maybe the patch to use a not insecure openssl is the source of the issue for you
same issue here - the sourceforge repo is way old, there's a github mirror but not maintained either, and there's a fork of the mirror which includes fixes for openssl 1.1.1:
I marked this as stale due to inactivity. →
Hmm, kinda forgot about this
I missed the fact that the "supported" branch didn't actually include the patch to fix this.


Question: sourceRoot = if stdenv.isDarwin then "" else "."; in callPackage ./generic.nix rec { <del> inherit sourceRoot; </del> <ins> inherit sourceRoot commandLineArgs; </ins> # Please backport all compatible updates to the stable release. # This is important for the extension ecosystem.


Question: clojure-vim/vim-jack-in cloudhead/neovim-fuzzy CoatiSoftware/vim-sourcetrail <ins> coc-extensions/coc-svelte </ins> cocopon/iceberg.vim codota/tabnine-vim cohama/lexima.vim

Project description Various vim plugins iamcco/coc-tailwindcss coc-extensions/coc-svelte evanleck/vim-svelte


Question: if [[ ! -e .git || ! -e VERSION ]]; then echo "${version}" > VERSION fi # Patch shebangs for script run during build patchShebangs --build "$configureScript" makeit e2e scripts mlocal/scripts # Patching the hard-coded defaultPath by prefixing the packages in defaultPathInputs substituteInPlace cmd/internal/cli/actions.go  --replace "defaultPath = "${defaultPathOriginal}"" "defaultPath = "''${defaultPathInputs// //bin:}''${defaultPathInputs:+/bin:}${defaultPathOriginal}"" <ins> substituteInPlace internal/pkg/util/gpu/nvidia.go  --replace  'return fmt.Errorf("/usr/bin not writable in the container")'  "" </ins> ''; postConfigure = ''

singularity cannot use nvidia gpu because it does not access 'nvidia-container-cli' Steps to reproduce the behavior: return result of ! This is because the path is not listed in , as also in a. It is caused by neither the option nor . I tried to handle it with override, but since it was called in , I think it is impossible to handle. Also, I created a conf file in as shown in the singularity docs, but it was not read. <!-- 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.
Thank you for reporting and sorry for the trouble. I'll look at the SingularityCE documentation again. (Those configuration options has been deprecated by Apptainer.) Also, I created a conf file in /usr/local/etc/singularity/ as shown in the singularity docs, but it was not read.  shold be what you are looking for. The overriden package can be assigned to . (If you would like to bypass all the overriding done by the module and directly specify the package to install for some special reason, you can assign it to .)
Thanks for the reply. I followed your advice and tried the override and was able to use the GPU. Here is the code This is simply adding a process to append the nvidia-docker path to the I mentioned earlier that when conf was entered in , it was not reflected, and the same is true for '/etc/singularity'. I referred to .
At least we have confirmed that in works and the path is replaced by , but the product does not seem to be recognizable.
Does setting the to make ldconfig search in help? This is modified from the configuration proposed by (). There's also (probably) related to this topic.
Adding the path of to works well. This once removed from consideration. Next we have a patched version of ldconfig. This does not append the path of to the config. The result was an error that could not be found, and it could not be started.
Oh, I already forgot about this issue. Absolutely coincidentally, but maybe efforts such as might open up a way to implement this hack more reliably.


Question: if [[ ! -e .git || ! -e VERSION ]]; then echo "${version}" > VERSION fi # Patch shebangs for script run during build patchShebangs --build "$configureScript" makeit e2e scripts mlocal/scripts # Patching the hard-coded defaultPath by prefixing the packages in defaultPathInputs substituteInPlace cmd/internal/cli/actions.go  --replace "defaultPath = "${defaultPathOriginal}"" "defaultPath = "''${defaultPathInputs// //bin:}''${defaultPathInputs:+/bin:}${defaultPathOriginal}"" <ins> substituteInPlace internal/pkg/util/gpu/nvidia.go  --replace  'return fmt.Errorf("/usr/bin not writable in the container")'  "" </ins> ''; postConfigure = ''

Meanwhile, in my config I'm still abusing You probably already have guessed, but singularity in nixpkgs is configured to read this config from the package-specific directory, rather than from the global . You could in principle override this behaviour, but there maybe isn't much value in supporting that
I tried to enable the use of external sysconfdir (), but have encountered issue trying to specify a directory under with the NixOS module ().
Have you tried to apply both at the same time?
The SingularityCE Admin Guide says If the value of nvidia-container-cli path is empty, SingularityCE will look for the binary on $PATH at runtime. It should work as long as is found in the run-time , even when is not set. As nvidia-container-cli is alredy included in the PATH-prefixing wrapper, we shouldn't have to set the .
Update: I found a bug in the prefixed PATH of the wrapper introduced in . The prefixing should be specified as (in Bash) I forgot to add , causing the trailing to be missing.
The statement in the SingularityCE Admin Guide turns out to be wrong / irrelevant. The source code clearly states that nvidia-container-cli will only be read from the configuration.
(we need to patch nvidia-container-cli, for many reasons )
Eh, actually, closed semi-automatically. Apptainer with is fixed (on NixOS), but not with . The fix doesn't concern singularity-ce either, unfortunately. Shouldn't be hard to make this work with singularity too, but I'm out of bandwidth
Hi folks, I've been trying to get apptainer to run this (which I've done previously successfully with a slight ldconfig hack -- that doesn't work anymore -- on NixOS 22.11), that will make use of the machine's Tesla V100 to do some simulation stuff. The machine is running NixOS 23.11. Using the workaround from 9th of May post further up, I was able to get past the ldconfig issue, but now I'm getting an error saying the driver and CUDA are not in sync.


Question: if [[ ! -e .git || ! -e VERSION ]]; then echo "${version}" > VERSION fi # Patch shebangs for script run during build patchShebangs --build "$configureScript" makeit e2e scripts mlocal/scripts # Patching the hard-coded defaultPath by prefixing the packages in defaultPathInputs substituteInPlace cmd/internal/cli/actions.go  --replace "defaultPath = "${defaultPathOriginal}"" "defaultPath = "''${defaultPathInputs// //bin:}''${defaultPathInputs:+/bin:}${defaultPathOriginal}"" <ins> substituteInPlace internal/pkg/util/gpu/nvidia.go  --replace  'return fmt.Errorf("/usr/bin not writable in the container")'  "" </ins> ''; postConfigure = ''

Before I start posting any details (I don't want to re-open this issue, but I'm also not sure if I'm just doing something wrong) I was wondering if the current implementation of singularity/apptainer on NixOS is expected to work, and I'm just being an idiot, or if there are known breaking issues? I've seen the other issues about singularity/apptainer here, but I'm not knowledgeable enough to make a judgement call if they are responsible for my problem or not. Thanks very much in advance!
(If I understood the message correctly) That usually means you need a reboot, and you should experience the same issue outside the container
No, the reboot didn't help either. For some reason, though, after upgrading to 24.05, everything "just works[tm]" again. So, whatever the issue was, thanks for fixing it (probably)! :)
Thanks to Nixpkgs 24.05 includes GPU-related changes/fixes to the package and the module.
Well more like thanks to ShamrockLee


Question: </listitem> <listitem> <para> <ins> The <literal>miller</literal> package has been upgraded from 5.10.3 to <link xlink:href="https://github.com/johnkerl/miller/releases/tag/v6.2.0">6.2.0</link>. See <link xlink:href="https://miller.readthedocs.io/en/latest/new-in-miller-6">What’s new in Miller 6</link>. </para> </listitem> <listitem> <para> </ins> MultiMC has been replaced with the fork PolyMC due to upstream developers being hostile to 3rd party package maintainers. PolyMC removes all MultiMC branding and is aimed at providing

<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: miller <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 5.10.3 desired version: 6.1.0 miller is now written in Go; there's still a configure script and a makefile, but I don't know if it's now more complicated to package because of fetching dependencies in a reproducible way or whatever. <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.


Question: librarypath="${lib.makeLibraryPath deps}:$libdir" wrapProgram $out/share/spotify/spotify  <ins> ''${gappsWrapperArgs[@]}  </ins> --prefix LD_LIBRARY_PATH : "$librarypath"  --prefix PATH : "${gnome.zenity}/bin"

Describe the bug When adding a local directory to spotify client, it always fails due to missing gtk schema(s) To Reproduce Steps to reproduce the behavior: on button Expected behavior Open a file chooser to select which directory to be . Screenshots If applicable, add screenshots to help explain your problem. Additional context Running spotify with flag from console gives me Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Maintainer information:
I think that this issue is not NixOS specific:
Still seems to be an issue. I'm using flakes so above is not applicable I'm on.
Tail end of strace.
Yep I can confirm that. However, as IvanMalison commented above, the bug might be not by nixos but by upstream.
I'm getting the same issue as OP when clicking the button I also tried this on EndeavourOS with the same version of spotify and there it works flawlessly. So I think this is actually a nixpkgs problem and not something upstream related. Maybe the issue can be reopened?


Question: } </programlisting> </para> <para> <del> Here's a recipe on how to override a particular plugin through an overlay: </del> <ins> Here's a recipe on how to override a particular plugin through an overlay: </ins> <programlisting> self: super: { postgresql_11 = super.postgresql_11.override { this = self.postgresql_11; } // {

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: } </programlisting> </para> <para> <del> Here's a recipe on how to override a particular plugin through an overlay: </del> <ins> Here's a recipe on how to override a particular plugin through an overlay: </ins> <programlisting> self: super: { postgresql_11 = super.postgresql_11.override { this = self.postgresql_11; } // {

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: <del> { stdenv, lib, fetchFromGitHub, cmake, pkg-config , mpg123, ffmpeg, libvorbis, libao, jansson, speex </del> <ins> { stdenv, lib, fetchFromGitHub, cmake, pkg-config, gtk3 , audacious, mpg123, ffmpeg, libvorbis, libao, jansson, speex </ins> , nix-update-script <ins> , buildAudaciousPlugin ? false  # only build cli by default, pkgs.audacious-plugins sets this to enable plugin support </ins> }: stdenv.mkDerivation rec {

The audacious package imports audacious-plugins to build most of the common plugins and then link them into the audacious lib path. However, this makes it hard to add more audacious plugins, like vgmstream. The vgmstream package currently has its , because importing the audacious package causes an infinite recursion error. Steps to reproduce the behavior: vgmstream to audacious-plugins buildInputs audacious to vgmstream's buildInputs and comment out the disable configure flag -shell -p audacious-plugins I expected that adding vgmstream to audacious-plugins would enable the plugin. Instead, the build crashes with an infinite recursion. How is it currently working for audacious to import audacious-plugins and audacious-plugins to import audacious? Can this same magic be extended to other plugins? This about how fcitx is packaged shows that fcitx-addons imports fcitx with no reverse import, should the audacious package be refactored to be similar? Should the audacious package gain an extra parameter to take extra plugin derivations, which can be created outside of the audacious-plugins derivation? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Instead of adding , did you try to add instead? is without as input, and it is used to break the loop.
Thank you for the quick response! That would be elegant, but I don't see any result in my grep of nixpkgs or in the .
Sorry, it is here: Basically you need to do and this should do the trick. Considering that we are going to use this in more than one place it probably makes sense to introduce it as a , but the result is the same regardless.
Oh that's a neat trick! I'll try that approach out next. Thank you so much! I tried out the extra-plugins approach here, seems to work but is not ergonomic:
I , and it's a lot easier to use as a user! If it looks good as an approach, please provide some review feedback and I'll squash it down for a PR :)
Shall I send a PR for a final review?


Question: extraInstallCommands = '' # Add desktop convencience stuff <del> mv $out/bin/{${name},${pname}} </del> <ins> mv $out/bin/{${pname}-*,${pname}} </ins> install -Dm444 ${appimageContents}/flexoptix-app.desktop -t $out/share/applications install -Dm444 ${appimageContents}/flexoptix-app.png -t $out/share/pixmaps substituteInPlace $out/share/applications/flexoptix-app.desktop

name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.


Question: , xdg-dbus-proxy , substituteAll , glib <ins> , addOpenGLRunpath </ins> }: assert enableGeoLocation -> geoclue2 != null;

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


Question: --replace "/etc/g810-led/profile" "${profile}" ''; <ins> # GCC 13 cannot find `uint16_t` and other similar types by default anymore env.CXXFLAGS = "-include cstdint"; </ins> buildInputs = [ hidapi ];

Steps to reproduce the behavior: g810-led Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: owner = "tailscale"; repo = "tailscale"; rev = "v${version}"; <del> hash = "sha256-aweJys46MMnkSKJoLUFCzc6sWUP+Cv5+IFVVe9iEPGI="; </del> <ins> hash = "sha256-jWnke49b6inybPmiZOkxI3C8VoYe4Syi84YhvL8zxeI="; </ins> }; <del> vendorHash = "sha256-oELDIt+mRiBGAdoEUkSAs2SM6urkHm1aAtJnev8jDYM="; </del> <ins> vendorHash = "sha256-Fr4VZcKrXnT1PZuEG110KBefjcZzRsQRBSvByELKAy4="; </ins> nativeBuildInputs = lib.optionals stdenv.isLinux [ makeWrapper ];

Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- 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.
You don't need to open an issue if you're going to make a PR right after.
Apologies, my bad. I was not aware :(. I am only 1 day & 1 PR old here.


Question: sha256 = "119kj2w0rrxkhg4f9cf5waa55jz1hj8933vh47vcjipcplql02bc"; }; <ins> patches = [ # Makes font a recognized media type. Committed upstream, but no release has been made. (fetchpatch { url = "https://gitlab.freedesktop.org/xdg/desktop-file-utils/commit/92af4108750ceaf4191fd54e255885c7d8a78b70.patch"; sha256 = "14sqy10p5skp6hv4hgiwnj9hpr460250x42k5z0390l6nr6gahsq"; }) ]; </ins> nativeBuildInputs = [ pkgconfig ]; buildInputs = [ glib libintl ];

I saw the following during a rebuild: Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/ttf" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/ttf" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/opentype" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/collection" is an invalid MIME type ("font" is an unregistered media type) Unknown system: host os: multi-user?: sandbox: version: nixpkgs:
I think we just need to update , c.f.
Ah, it seems that upstream has not released a version with the fixed commit in. The last tagged release was , they haven't tagged anything with the fix commit in. We could build from their git head, I guess, although I'm reluctant to do so. Perhaps complain ?
If the commit applies as a patch that would also be fine.
I'm still having this. had it for build and build (separately). build


Question: --prefix PATH ":" "${erlang}/bin:${coreutils}/bin:${curl}/bin:${bash}/bin"  --set CURL_CA_BUNDLE /etc/ssl/certs/ca-certificates.crt done <ins> substituteInPlace $out/bin/mix  --replace "/usr/bin/env elixir" "${coreutils}/bin/env $out/bin/elixir" </ins> ''; meta = with stdenv.lib; {

I'm using Nix 1.9 on OS X 10.10.4 (Yosemite) with the package. It installs without issues, but when I try to use the tool I get this error: I'm using the unstable channel:
Hrm, I get (also Nix 1.9 and OS X 10.10.4) It seems to be an issue with the shebang in as seems to work just fine. I don't see anything obviously wrong with though... (PS hi long time no see :)
I just hit this issue too. Weirdly, just running from different shells would give different errors (I use fish normally, so it's always an early suspect around problems like this). I would get an error like got from , and an error like from . When I change my to this: Everything works, and in all shells the same way. Is this a valid fix? (By "works", I mean I get , but maybe that's a separate issue, or due to a lack of familiarity with Elixir/Erlang...)
Nice catch. Doing will generate a new app skeleton if everything is working as it should.
Turns out I just forgot to put the at the end of my fixed version, so no args were getting through :P Is what I mentioned above an acceptable fix? If so, I can submit a PR.


Question: , wayland-scanner , libdrm , zlib <ins> , nixosTests </ins> # Set as 'false' to build monado without service support, i.e. allow VR # applications linking against libopenxr_monado.so to use OpenXR standalone # instead of via the monado-service program. For more information see:

The [monado] package doesn't install the udev rules generated by the [xr-hardware util] from the Monado project. Install the package and check the lack of udev rules in It was expected for the udev rules to be installted with the package. The udev rules are needed as some hmd's have some strange and specific permissions. Maybe instead of adding this to the package, monado could turn into an option like . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: [monado]: [xr-hardware util]:
Trying packaging the udev rules similar to how . [brscan4]:
I was working on a Monado NixOS module. Perhaps I can deal with udev rules there. See


Question: yanone-kaffeesatz = callPackage ../data/fonts/yanone-kaffeesatz {}; <ins> yaru-theme = callPackage ../data/themes/yaru {}; </ins> zafiro-icons = callPackage ../data/icons/zafiro-icons { }; zeal = libsForQt5.callPackage ../data/documentation/zeal { };

Project description Metadata homepage URL: source URL: license: lgpl2/lgpl3 platforms: linux
Previously: (which I never finished, sorry, but linking in case helps anyone tackle this).


Question: configureFlags = common.configureFlags ++ [ "--without-x" ] # disable xdvik and xpdfopen ++ map (what: "--disable-${what}") ([ <ins> "chktex" </ins> "dvisvgm" "dvipng" # ghostscript dependency "luatex" "luajittex" "mp" "pmp" "upmp" "mf" # cairo would bring in X and more "xetex" "bibtexu" "bibtex8" "bibtex-x" "upmendex" # ICU isn't small

I've hit the same bug as described in The root of the problem seems to be missing configuration file which should be placed somewhere and made accessible by . It is used by, for example, in Emacs. cc
cc
I'm just getting this warning: Otherwise the output seems normal to me, but I've never really used the utility.
Oh, I see, is still a problem, as it used to be in Debian.
Actually, that config file is provided by package, so if I include it in , it works fine even with . Still, it's a bit confusing that the core provides binary but doesn't fully support it.
I currently can't see a simple way how to improve that.
I am not able to use on because it does not accept the option . In the command line I get: Is it related to this issue, or should I report a new issue?
cc When explicitly adding to there are checksum errors. The following patch fixes it for me: With that, does not give the error anymore.
Oh, no, they're updating files in-place on the only mirror. Many of them won't download anymore :angry:
Better discuss the mirroring stuff at this thread:
triage: this might have been fixed in the meantime, is that so?
it's still necessary to explicitly add the package, otherwise the problem persists.
Could anyone, please, provide steps to reproduce?
The "chktex -v" works for me, I have installed with .
works in but not .
This issue still persists as of today under the tetex scheme. the addition of the chktex package is mandatory to not get this error. I was getting this error in emacs: chktex: WARNING -- Could not find global resource file. chktex: ERROR -- Illegal verbosity level. I didn't thought that this was a NixOS related issue so this thread was quite hard to stumble upon.
I can't reproduce:
I guess I forgot . If I include that then it just gives "chktex: command not found". So how do I trigger the issue?


Question: <ins> [Nemo Action] Active=true Name=Open in Pulsar Comment=Open in Pulsar #%U is the current selected file, this will also work on current directory Exec=pulsar -n %U Icon-Name=pulsar Selection=any Extensions=any </ins>

Package name: pulsar Latest released version: 1.117.0 Current version on the unstable channel: 1.114.0 Current version on the stable/release channel: 1.117.0 Notify maintainers


Question: # Whether to compile with SUID support , enableSuid ? false , starterSuidPath ? null <ins> , substituteAll </ins> # newuidmapPath and newgidmapPath are to support --fakeroot # where those SUID-ed executables are unavailable from the FHS system PATH. # Path to SUID-ed newuidmap executable

singularity cannot use nvidia gpu because it does not access 'nvidia-container-cli' Steps to reproduce the behavior: return result of ! This is because the path is not listed in , as also in a. It is caused by neither the option nor . I tried to handle it with override, but since it was called in , I think it is impossible to handle. Also, I created a conf file in as shown in the singularity docs, but it was not read. <!-- 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.
Thank you for reporting and sorry for the trouble. I'll look at the SingularityCE documentation again. (Those configuration options has been deprecated by Apptainer.) Also, I created a conf file in /usr/local/etc/singularity/ as shown in the singularity docs, but it was not read.  shold be what you are looking for. The overriden package can be assigned to . (If you would like to bypass all the overriding done by the module and directly specify the package to install for some special reason, you can assign it to .)
Thanks for the reply. I followed your advice and tried the override and was able to use the GPU. Here is the code This is simply adding a process to append the nvidia-docker path to the I mentioned earlier that when conf was entered in , it was not reflected, and the same is true for '/etc/singularity'. I referred to .
At least we have confirmed that in works and the path is replaced by , but the product does not seem to be recognizable.
Does setting the to make ldconfig search in help? This is modified from the configuration proposed by (). There's also (probably) related to this topic.
Adding the path of to works well. This once removed from consideration. Next we have a patched version of ldconfig. This does not append the path of to the config. The result was an error that could not be found, and it could not be started.
Oh, I already forgot about this issue. Absolutely coincidentally, but maybe efforts such as might open up a way to implement this hack more reliably.


Question: # Whether to compile with SUID support , enableSuid ? false , starterSuidPath ? null <ins> , substituteAll </ins> # newuidmapPath and newgidmapPath are to support --fakeroot # where those SUID-ed executables are unavailable from the FHS system PATH. # Path to SUID-ed newuidmap executable

Meanwhile, in my config I'm still abusing You probably already have guessed, but singularity in nixpkgs is configured to read this config from the package-specific directory, rather than from the global . You could in principle override this behaviour, but there maybe isn't much value in supporting that
I tried to enable the use of external sysconfdir (), but have encountered issue trying to specify a directory under with the NixOS module ().
Have you tried to apply both at the same time?
The SingularityCE Admin Guide says If the value of nvidia-container-cli path is empty, SingularityCE will look for the binary on $PATH at runtime. It should work as long as is found in the run-time , even when is not set. As nvidia-container-cli is alredy included in the PATH-prefixing wrapper, we shouldn't have to set the .
Update: I found a bug in the prefixed PATH of the wrapper introduced in . The prefixing should be specified as (in Bash) I forgot to add , causing the trailing to be missing.
The statement in the SingularityCE Admin Guide turns out to be wrong / irrelevant. The source code clearly states that nvidia-container-cli will only be read from the configuration.
(we need to patch nvidia-container-cli, for many reasons )
Eh, actually, closed semi-automatically. Apptainer with is fixed (on NixOS), but not with . The fix doesn't concern singularity-ce either, unfortunately. Shouldn't be hard to make this work with singularity too, but I'm out of bandwidth
Hi folks, I've been trying to get apptainer to run this (which I've done previously successfully with a slight ldconfig hack -- that doesn't work anymore -- on NixOS 22.11), that will make use of the machine's Tesla V100 to do some simulation stuff. The machine is running NixOS 23.11. Using the workaround from 9th of May post further up, I was able to get past the ldconfig issue, but now I'm getting an error saying the driver and CUDA are not in sync.


Question: # Whether to compile with SUID support , enableSuid ? false , starterSuidPath ? null <ins> , substituteAll </ins> # newuidmapPath and newgidmapPath are to support --fakeroot # where those SUID-ed executables are unavailable from the FHS system PATH. # Path to SUID-ed newuidmap executable

Before I start posting any details (I don't want to re-open this issue, but I'm also not sure if I'm just doing something wrong) I was wondering if the current implementation of singularity/apptainer on NixOS is expected to work, and I'm just being an idiot, or if there are known breaking issues? I've seen the other issues about singularity/apptainer here, but I'm not knowledgeable enough to make a judgement call if they are responsible for my problem or not. Thanks very much in advance!
(If I understood the message correctly) That usually means you need a reboot, and you should experience the same issue outside the container
No, the reboot didn't help either. For some reason, though, after upgrading to 24.05, everything "just works[tm]" again. So, whatever the issue was, thanks for fixing it (probably)! :)
Thanks to Nixpkgs 24.05 includes GPU-related changes/fixes to the package and the module.
Well more like thanks to ShamrockLee


Question: <ins> { buildGoPackage , fetchFromGitHub , lib }: # upstream is pretty stale, but it still works, so until they merge module # support we have to use gopath: see blynn/nex#57 buildGoPackage rec { pname = "nex"; version = "unstable-2021-03-30"; src = fetchFromGitHub { owner = "blynn"; repo = pname; rev = "1a3320dab988372f8910ccc838a6a7a45c8980ff"; hash = "sha256-DtJkV380T2B5j0+u7lYZfbC0ej0udF4GW2lbRmmbjAM="; }; goPackagePath = "github.com/blynn/nex"; subPackages = [ "." ]; meta = with lib; { description = "Lexer for Go"; homepage = "https://github.com/blynn/nex"; license = licenses.gpl3Only; maintainers = with maintainers; [ urandom ]; }; } </ins>

Project description mgmt: next generation config management! Metadata homepage URL: source URL: license: GNU3 platforms: unix, linux, darwin
After fixing up the mgmt make scripts , from !/bin/bash to !/usr/bin/env bash trying to build from 'nix-shell -p go git' git clone cd mgmt make path make deps make Building: mgmt, os/arch: linux-amd64, version: 0.0.21-90-g5c6a66e-dirty. go build runtime/cgo: copying /run/user/1000/go-build892927552/b057/pkg.a: open /nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go/pkg/linuxamd64/runtime/cgo.a: read-only file system make: * [Makefile:175: build/mgmt-linux-amd64] Error 1 go env GO111MODULE="" GOARCH="amd64" GOBIN="/home/demo/gopath/bin/" GOCACHE="" GOENV="" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/demo/gopath/" GOPRIVATE="" GOPROXY=",direct" GOROOT="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go" GOSUMDB="" GOTMPDIR="" GOTOOLDIR="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.


Question: <ins> { buildGoPackage , fetchFromGitHub , lib }: # upstream is pretty stale, but it still works, so until they merge module # support we have to use gopath: see blynn/nex#57 buildGoPackage rec { pname = "nex"; version = "unstable-2021-03-30"; src = fetchFromGitHub { owner = "blynn"; repo = pname; rev = "1a3320dab988372f8910ccc838a6a7a45c8980ff"; hash = "sha256-DtJkV380T2B5j0+u7lYZfbC0ej0udF4GW2lbRmmbjAM="; }; goPackagePath = "github.com/blynn/nex"; subPackages = [ "." ]; meta = with lib; { description = "Lexer for Go"; homepage = "https://github.com/blynn/nex"; license = licenses.gpl3Only; maintainers = with maintainers; [ urandom ]; }; } </ins>

8/share/go/pkg/tool/linuxamd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGOENABLED="1" GOMOD="" CGOCFLAGS="-g -O2" CGOCPPFLAGS="" CGOCXXFLAGS="-g -O2" CGOFFLAGS="-g -O2" CGOLDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/run/user/1000/go-build275716735=/tmp/go-build -gno-record-gcc-switches"
mgmt now compiles under a I'm going to need a little bit of help to turn this into a nix package, as i'm not too sure how to handle it , as there are buildgopackage, buildgomodule , vgo2nix etc etc . Any pointers welcomed. to avoid I had to remove the -i from the go build this seems to be related to this NixOS/nixpkgs golang/go to run
I marked this as stale due to inactivity. →


Question: # require networking "tests/test_init.py" "tests/test_matching.py" <ins> "tests/providers/lyrics" "tests/types" "tests/utils/test_github.py" </ins> "tests/utils/test_m3u.py" "tests/utils/test_metadata.py" "tests/utils/test_search.py"

Steps to reproduce the behavior: spotdl I just tried to install it, doing it from or gives the same result. Let me know if I can provide more useful information.


Question: ecdsa = callPackage ../development/python-modules/ecdsa { }; <ins> echo = callPackage ../development/python-modules/echo { }; </ins> ecoaliface = callPackage ../development/python-modules/ecoaliface { }; ecos = callPackage ../development/python-modules/ecos { };

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: stdenv.mkDerivation rec { pname = "authenticator"; <del> version = "4.1.6"; </del> <ins> version = "4.2.0"; </ins> src = fetchFromGitLab { domain = "gitlab.gnome.org"; owner = "World"; repo = "Authenticator"; rev = version; <del> hash = "sha256-fv7Np3haRCJABlJocKuu+1jevHYrdo+VyiQBpRmHs2g="; </del> <ins> hash = "sha256-Nv4QE6gyh42Na/stAgTIapV8GQuUHCdL6IEO//J8dV8="; </ins> }; cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; <del> hash = "sha256-8GddlDM1lU365GXdrKNhO331/y1p3Om5uZfVLy8TBGI="; </del> <ins> hash = "sha256-IS9jdr19VvgX6M1OqM6rjE8veujZcwBuOTuDm5mDXso="; </ins> }; nativeBuildInputs = [

The application fails to start with the following error: Steps to reproduce the behavior: to run the application The application should start and work properly.
Same issue with  (
I was looking at fractal-next as well, and found possibly related - [HELP] "Failed to retrieve template child" for Rust 1.67.0-nightly - Dec 4, 2022 - closed with Fixed in 0.5.3 a day later.
Ah, I see. There is a related PR for Amberol:
What commit did you build from? I’d like to bisect
My first try of fractal-next was about a week ago and it was failing already. I've tried HEAD and branch () although I'm not entlrely sure is the correct way to refer to that branch.
if you’re updating the version to point to an unreleased version the should
Indeed, thanks. What I meant was that I'm not entirely sure that setting in to (via ) does indeed let me build from a branch. I could not find a definitive reference for that, but it seems to work. I've the rust backtrace to - Draft: general: Use AdwDualPaneView and AdwAdaptiveState_
Hi there :) This is an unfortunate gtk-rs bug, and there's nothing to do on the app side for this. In addition, draft MRs are not expected to be packaged. That MR in particular depends on unstable libadwaita features and unstable bindings.
Is the gtk-rs package version something I can control? I was under the impression that this is managed in . I understand the branches/merge-requests I tried are not to be packaged. I'm merely trying to get fractal-next to run at all, as element is unusable on my phone.
In it is the minimum version we want to use. The pinned version (the one that is compiled) is in , and it is currently  on . This issue should have been fixed in . I don't know much about packaging for Nix but looking at the diff you posted , have you tried with the whole commit hash? Also don't you need to update the sha256 hash?
We’re not building from , we’re building from . I’m gonna check if we can just bump the version in to and leave it at that.
(how naive of me.


Question: stdenv.mkDerivation rec { pname = "authenticator"; <del> version = "4.1.6"; </del> <ins> version = "4.2.0"; </ins> src = fetchFromGitLab { domain = "gitlab.gnome.org"; owner = "World"; repo = "Authenticator"; rev = version; <del> hash = "sha256-fv7Np3haRCJABlJocKuu+1jevHYrdo+VyiQBpRmHs2g="; </del> <ins> hash = "sha256-Nv4QE6gyh42Na/stAgTIapV8GQuUHCdL6IEO//J8dV8="; </ins> }; cargoDeps = rustPlatform.fetchCargoTarball { inherit src; name = "${pname}-${version}"; <del> hash = "sha256-8GddlDM1lU365GXdrKNhO331/y1p3Om5uZfVLy8TBGI="; </del> <ins> hash = "sha256-IS9jdr19VvgX6M1OqM6rjE8veujZcwBuOTuDm5mDXso="; </ins> }; nativeBuildInputs = [

maybe just building from is better)
Opened a PR that should solve this, assuming it's accepted. In the meantime you can use it in an overlay if you want a fix now.
You were right - thanks for the hint! - I was indeed still building fractal-next from before the fix :disappointed:


Question: '' # Following is required to prevent a build error: # ninja: error: '/nix/store/z8z04p0ph48w22rqzx7ql67gy8cyvidi-SDKs/MacOSX10.12.sdk/usr/include/mach/exc.defs', needed by 'gen/third_party/crashpad/crashpad/util/mach/excUser.c', missing and no known rule to make it <del> + (optionalString (lib.versionAtLeast qtCompatVersion "5.11") '' </del> <ins> + '' </ins> substituteInPlace src/3rdparty/chromium/third_party/crashpad/crashpad/util/BUILD.gn  --replace '$sysroot/usr' "${darwin.xnu}" <del> '') </del> <ins> '' </ins> + '' # Apple has some secret stuff they don't share with OpenBSM substituteInPlace src/3rdparty/chromium/base/mac/mach_port_broker.mm

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: postPatch = '' # relax version bounds <del> sed -i 's/([A-z0-9]*)~=.*$/1/' setup.cfg </del> <ins> sed -i -E 's/([A-z0-9]*)~=[^;]*(.*)/12/' setup.cfg </ins> ''; <del> propagatedBuildInputs = with python3.pkgs; [ bitmath certifi cheroot cryptography filetype flask flask-babel flask-caching flask-compress flask-session flask-themes2 js2py pycurl semver setuptools ]; </del> <ins> dependencies = with python3.pkgs; [ bitmath certifi cheroot cryptography filetype flask flask-babel flask-caching flask-compress flask-session flask-themes2 pycurl semver setuptools ] ++ (if pythonOlder "3.12" then [ js2py ] else [ dukpy ]); </ins> <del> passthru = { optional-dependencies = { plugins = with python3.pkgs; [ beautifulsoup4 # for some plugins colorlog # colorful console logging pillow # for some CAPTCHA plugin send2trash # send some files to trash instead of deleting them slixmpp # XMPP plugin ]; }; </del> <ins> optional-dependencies = { plugins = with python3.pkgs; [ beautifulsoup4 # for some plugins colorlog # colorful console logging pillow # for some CAPTCHA plugin send2trash # send some files to trash instead of deleting them slixmpp # XMPP plugin ]; }; </ins> <del> tests = { inherit (nixosTests) pyload; }; </del> <ins> passthru.tests = { inherit (nixosTests) pyload; </ins> }; <del> meta = with lib; { </del> <ins> meta = { </ins> description = "Free and open-source download manager with support for 1-click-hosting sites"; homepage = "https://github.com/pyload/pyload"; <del> license = licenses.agpl3Plus; maintainers = with maintainers; [ ruby0b ]; </del> <ins> license = lib.licenses.agpl3Plus; maintainers = with lib.maintainers; [ ruby0b ]; </ins> mainProgram = "pyload"; }; }

Steps to reproduce the behavior: pyload-ng <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thank you for notifying me, the failure is caused by the lib not yet working on python 3.12. Apparently the git upstream of pyload replaced it with which I'm packaging in , so once that's done I'll get around to updating pyload (will probably have to switch to the git version since they rarely upload new releases to pypi). For now you can override the python version as a workaround:
The override works great. Thanks!


Question: thrift beautifulsoup4 markdown2 <del> sqlalchemy7 </del> <ins> sqlalchemy </ins> html2text evernote ];

To make sure that we are on the same page: Kernel: System: Nix version: Nixpkgs version: broke legacy packages (only tested with the -set). Multiple options to solve this: revert the commit (an update will eventually have to be done) make sure no-one depends on sqlalchemy legacy versions (this would be the best choice, but can require a big amount of work) re-introduce an outdated version only used by legacy version (I’ll prepare a PR shortly that follows this path) cc
To be complete, the build problem is a test failure: I also checked, we cannot downgrade sqlite only for few pythonPackages, the entire python (and package set) have to be changed. Any preferred way to go?
(We should check if we still need this version, have it removed locally for virtmanager, virtinst as it isn't used, but haven't had the time to push that)
Yes, this is the preferred way to go. I began that but did not finish it yet, and it impacts some important parts (it causes xen to fail) I would prefer not to break because of unsufficient testing from me. This is in progress but could require some time to complete.
FYI xen already fails on
FYI: I switched away from sqlalchemy7 in yesterday.
Apart from virtinst, acd_cli, beaker, coilmq, and geeknote are the only revdeps of sqlalchemy7, as far as I can tell.
I openned to do some cleanup on sqlalchemy7. There still is that explicitly require . The same work will have to be done for and .
This should have remained open.
Using an older version of sqlite requires overriding the derivations of the interpreters.
See