Question: <del> Index: include/VBox/sup.h =================================================================== --- trunk/include/VBox/sup.h	(revision 151556) +++ trunk/include/VBox/sup.h	(working copy) @@ -2142,6 +2142,26 @@ */ SUPR0DECL(uint32_t) SUPR0GetKernelFeatures(void); +/** + * Notification from R0 VMM prior to loading the guest-FPU register state. + * + * @returns Whether the host-FPU register state has been saved by the host kernel. + * @param   fCtxHook    Whether thread-context hooks are enabled. + * + * @remarks Called with preemption disabled. + */ +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook); + +/** + * Notification from R0 VMM prior to saving the guest-FPU register state (and + * potentially restoring the host-FPU register state) in ring-0. + * + * @param   fCtxHook    Whether thread-context hooks are enabled. + * + * @remarks Called with preemption disabled. + */ +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook); + /** @copydoc RTLogGetDefaultInstanceEx * @remarks To allow overriding RTLogGetDefaultInstanceEx locally. */ SUPR0DECL(struct RTLOGGER *) SUPR0GetDefaultLogInstanceEx(uint32_t fFlagsAndGroup); Index: src/VBox/Additions/linux/sharedfolders/regops.c =================================================================== --- trunk/src/VBox/Additions/linux/sharedfolders/regops.c	(revision 151556) +++ trunk/src/VBox/Additions/linux/sharedfolders/regops.c	(working copy) @@ -3823,7 +3823,9 @@ .readpage       = vbsf_readpage, .writepage      = vbsf_writepage, /** @todo Need .writepages if we want msync performance...  */ -#if RTLNX_VER_MIN(2,5,12) +#if RTLNX_VER_MIN(5,18,0) +    .dirty_folio = filemap_dirty_folio, +#elif RTLNX_VER_MIN(2,5,12) .set_page_dirty = __set_page_dirty_buffers, #endif #if RTLNX_VER_MIN(5,14,0) Index: src/VBox/Additions =================================================================== --- trunk/src/VBox/Additions	(revision 151556) +++ trunk/src/VBox/Additions	(working copy) Property changes on: src/VBox/Additions ___________________________________________________________________ Modified: svn:mergeinfo ## -0,0 +0,1 ## Merged /trunk/src/VBox/Additions:r150844 Index: src/VBox/HostDrivers/Support/SUPDrv.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/SUPDrv.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/SUPDrv.cpp	(working copy) @@ -98,6 +98,18 @@ # endif #endif +#if defined(RT_OS_LINUX) && !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) && defined(CONFIG_FORTIFY_SOURCE) +/* In Linux 5.18-rc1, memcpy became a wrapper which does fortify checks + * before triggering __underlying_memcpy() call. We do not pass these checks here, + * so bypass them for now.  */ +# if RTLNX_VER_MIN(5,18,0) +#  define SUPDRV_MEMCPY __underlying_memcpy +# else +# define SUPDRV_MEMCPY  memcpy +# endif +#else +# define SUPDRV_MEMCPY  memcpy +#endif /* * Logging assignments: @@ -266,6 +278,8 @@ SUPEXP_STK_BACK(    2,  SUPR0ContFree), SUPEXP_STK_BACK(    2,  SUPR0ChangeCR4), SUPEXP_STK_BACK(    1,  SUPR0EnableVTx), +    SUPEXP_STK_OKAY(    1,  SUPR0FpuBegin), +    SUPEXP_STK_OKAY(    1,  SUPR0FpuEnd), SUPEXP_STK_BACK(    0,  SUPR0SuspendVTxOnCpu), SUPEXP_STK_BACK(    1,  SUPR0ResumeVTxOnCpu), SUPEXP_STK_OKAY(    1,  SUPR0GetCurrentGdtRw), @@ -1742,7 +1756,7 @@ /* execute */ pReq->u.Out.cFunctions = RT_ELEMENTS(g_aFunctions); -            memcpy(&pReq->u.Out.aFunctions[0], g_aFunctions, sizeof(g_aFunctions)); +            SUPDRV_MEMCPY(&pReq->u.Out.aFunctions[0], g_aFunctions, sizeof(g_aFunctions)); pReq->Hdr.rc = VINF_SUCCESS; return 0; } Index: src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp	(working copy) @@ -2002,6 +2002,18 @@ } +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + /* * * org_virtualbox_SupDrv Index: src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c =================================================================== --- trunk/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c	(working copy) @@ -640,3 +640,16 @@ return 0; } + +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + Index: src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c =================================================================== --- trunk/src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c	(working copy) @@ -1454,6 +1454,31 @@ } +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +#if RTLNX_VER_MIN(5,18,0) +    kernel_fpu_begin(); +    /* if (fCtxHook) */ +        preempt_enable();  /* HACK ALERT! undo the implicit preempt_disable() in kernel_fpu_begin(). */ +    return true; +#else +    return false; +#endif +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +#if RTLNX_VER_MIN(5,18,0) +    /* if (fCtxHook) */ +        preempt_disable();  /* HACK ALERT! undo the implicit preempt_enable() in SUPR0FpuBegin(). */ +    kernel_fpu_end(); +#endif +} + + int VBOXCALL    supdrvOSGetCurrentGdtRw(RTHCUINTPTR *pGdtRw) { #if RTLNX_VER_MIN(4,12,0) Index: src/VBox/HostDrivers/Support/os2/SUPDrv-os2.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/os2/SUPDrv-os2.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/os2/SUPDrv-os2.cpp	(working copy) @@ -541,3 +541,16 @@ return 0; } + +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + Index: src/VBox/HostDrivers/Support/solaris/SUPDrv-solaris.c =================================================================== --- trunk/src/VBox/HostDrivers/Support/solaris/SUPDrv-solaris.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/solaris/SUPDrv-solaris.c	(working copy) @@ -1309,3 +1309,16 @@ return 0; } + +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + Index: src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp	(working copy) @@ -2704,6 +2704,19 @@ } +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + + SUPR0DECL(int) SUPR0IoCtlSetupForHandle(PSUPDRVSESSION pSession, intptr_t hHandle, uint32_t fFlags, PSUPR0IOCTLCTX *ppCtx) { /* Index: src/VBox/HostDrivers/VBoxNetFlt/linux/VBoxNetFlt-linux.c =================================================================== --- trunk/src/VBox/HostDrivers/VBoxNetFlt/linux/VBoxNetFlt-linux.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/VBoxNetFlt/linux/VBoxNetFlt-linux.c	(working copy) @@ -2311,7 +2311,13 @@ vboxNetFltDumpPacket(pSG, true, "host", (fDst & INTNETTRUNKDIR_WIRE) ? 0 : 1); Log6(("vboxNetFltPortOsXmit: pBuf->cb dump:n%.*Rhxdn", sizeof(pBuf->cb), pBuf->cb)); Log6(("vboxNetFltPortOsXmit: netif_rx_ni(%p)n", pBuf)); +#if RTLNX_VER_MIN(5,18,0) +                local_bh_disable(); +                err = netif_rx(pBuf); +                local_bh_enable(); +#else err = netif_rx_ni(pBuf); +#endif if (err) rc = RTErrConvertFromErrno(err); } Index: src/VBox/VMM/VMMR0/CPUMR0.cpp =================================================================== --- trunk/src/VBox/VMM/VMMR0/CPUMR0.cpp	(revision 151556) +++ trunk/src/VBox/VMM/VMMR0/CPUMR0.cpp	(working copy) @@ -440,6 +440,9 @@ Assert(!(pVCpu->cpum.s.fUseFlags & CPUM_USED_FPU_GUEST)); Assert(!(pVCpu->cpum.s.fUseFlags & CPUM_SYNC_FPU_STATE)); +    /* Notify the support driver prior to loading the guest-FPU register state. */ +    SUPR0FpuBegin(false /* unused */); + if (!pVM->cpum.s.HostFeatures.fLeakyFxSR) { Assert(!(pVCpu->cpum.s.fUseFlags & CPUM_USED_MANUAL_XMM_RESTORE)); @@ -484,6 +487,9 @@ Assert(ASMGetCR4() & X86_CR4_OSFXSR); if (pVCpu->cpum.s.fUseFlags & (CPUM_USED_FPU_GUEST | CPUM_USED_FPU_HOST)) { +        /* Notify the support driver prior to loading the host-FPU register state. */ +        SUPR0FpuEnd(false /* unused */); + fSavedGuest = RT_BOOL(pVCpu->cpum.s.fUseFlags & CPUM_USED_FPU_GUEST); if (!(pVCpu->cpum.s.fUseFlags & CPUM_USED_MANUAL_XMM_RESTORE)) cpumR0SaveGuestRestoreHostFPUState(&pVCpu->cpum.s); </del>

Virtualbox corrupts guest filesystems by randomly flipping bits when the guest writes data to the virtual hard disks. virtualbox on the host with a new virtual machine for linux 2.6/3.x/4.x with default settings (1GiB RAM, 8GiB harddisk). "Insert" a linux live medium into the virtual CD drive. The virtual hard disk should be placed on a filesystem on a physical hard disk (the bug cannot be triggered if the virtual hard disk is placed on a tmpfs, see below). the machine and open a root shell after booting. these commands inside the guest's root shell to write random data onto the hard disk, then read it back and compare it: Caution: This will overwrite anything on the guest's virtual hard disk The shown hashes should match, but in 90% of test runs, they won't. This bug makes virtualbox quite unreliable: It is still possible to install NixOS inside a virtualbox, but during installation, Nix will report a couple of checksum failures, and sometimes the installation is to be tried more then once. After that, random failures of random programs occur. If btrfs is used, this will also complain about checksum errors. After observing this on my production machine with NixOS 22.05, I tried narrowing down the offending commit. To this end, I adapted the nixpkgs minimal live cd build recipe to build an image with virtualbox installed on it, and built this agains different nixpkgs versions. So most of my tests have been performed on a test machine booted from a usb flash drive. The offending commit seems to be . I guess that commit brings in some kernel patch, which is incompatible with the way virtualbox handles disk images. The bug occurs when the host's filesystem containing the disk image is or . In both cases, I tried with freshly created filesystems. The bug does not occur if the disk image is on (or it occurs with very low probablity). I haven't tried any other filesystems on the host. Just to be sure there isn't a general problem with virtualization: I failed to reproduce the bug with qemu and a qcow2 disk image. So it seems to be a virtualbox-only problem.


Question: <del> Index: include/VBox/sup.h =================================================================== --- trunk/include/VBox/sup.h	(revision 151556) +++ trunk/include/VBox/sup.h	(working copy) @@ -2142,6 +2142,26 @@ */ SUPR0DECL(uint32_t) SUPR0GetKernelFeatures(void); +/** + * Notification from R0 VMM prior to loading the guest-FPU register state. + * + * @returns Whether the host-FPU register state has been saved by the host kernel. + * @param   fCtxHook    Whether thread-context hooks are enabled. + * + * @remarks Called with preemption disabled. + */ +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook); + +/** + * Notification from R0 VMM prior to saving the guest-FPU register state (and + * potentially restoring the host-FPU register state) in ring-0. + * + * @param   fCtxHook    Whether thread-context hooks are enabled. + * + * @remarks Called with preemption disabled. + */ +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook); + /** @copydoc RTLogGetDefaultInstanceEx * @remarks To allow overriding RTLogGetDefaultInstanceEx locally. */ SUPR0DECL(struct RTLOGGER *) SUPR0GetDefaultLogInstanceEx(uint32_t fFlagsAndGroup); Index: src/VBox/Additions/linux/sharedfolders/regops.c =================================================================== --- trunk/src/VBox/Additions/linux/sharedfolders/regops.c	(revision 151556) +++ trunk/src/VBox/Additions/linux/sharedfolders/regops.c	(working copy) @@ -3823,7 +3823,9 @@ .readpage       = vbsf_readpage, .writepage      = vbsf_writepage, /** @todo Need .writepages if we want msync performance...  */ -#if RTLNX_VER_MIN(2,5,12) +#if RTLNX_VER_MIN(5,18,0) +    .dirty_folio = filemap_dirty_folio, +#elif RTLNX_VER_MIN(2,5,12) .set_page_dirty = __set_page_dirty_buffers, #endif #if RTLNX_VER_MIN(5,14,0) Index: src/VBox/Additions =================================================================== --- trunk/src/VBox/Additions	(revision 151556) +++ trunk/src/VBox/Additions	(working copy) Property changes on: src/VBox/Additions ___________________________________________________________________ Modified: svn:mergeinfo ## -0,0 +0,1 ## Merged /trunk/src/VBox/Additions:r150844 Index: src/VBox/HostDrivers/Support/SUPDrv.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/SUPDrv.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/SUPDrv.cpp	(working copy) @@ -98,6 +98,18 @@ # endif #endif +#if defined(RT_OS_LINUX) && !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) && defined(CONFIG_FORTIFY_SOURCE) +/* In Linux 5.18-rc1, memcpy became a wrapper which does fortify checks + * before triggering __underlying_memcpy() call. We do not pass these checks here, + * so bypass them for now.  */ +# if RTLNX_VER_MIN(5,18,0) +#  define SUPDRV_MEMCPY __underlying_memcpy +# else +# define SUPDRV_MEMCPY  memcpy +# endif +#else +# define SUPDRV_MEMCPY  memcpy +#endif /* * Logging assignments: @@ -266,6 +278,8 @@ SUPEXP_STK_BACK(    2,  SUPR0ContFree), SUPEXP_STK_BACK(    2,  SUPR0ChangeCR4), SUPEXP_STK_BACK(    1,  SUPR0EnableVTx), +    SUPEXP_STK_OKAY(    1,  SUPR0FpuBegin), +    SUPEXP_STK_OKAY(    1,  SUPR0FpuEnd), SUPEXP_STK_BACK(    0,  SUPR0SuspendVTxOnCpu), SUPEXP_STK_BACK(    1,  SUPR0ResumeVTxOnCpu), SUPEXP_STK_OKAY(    1,  SUPR0GetCurrentGdtRw), @@ -1742,7 +1756,7 @@ /* execute */ pReq->u.Out.cFunctions = RT_ELEMENTS(g_aFunctions); -            memcpy(&pReq->u.Out.aFunctions[0], g_aFunctions, sizeof(g_aFunctions)); +            SUPDRV_MEMCPY(&pReq->u.Out.aFunctions[0], g_aFunctions, sizeof(g_aFunctions)); pReq->Hdr.rc = VINF_SUCCESS; return 0; } Index: src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp	(working copy) @@ -2002,6 +2002,18 @@ } +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + /* * * org_virtualbox_SupDrv Index: src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c =================================================================== --- trunk/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c	(working copy) @@ -640,3 +640,16 @@ return 0; } + +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + Index: src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c =================================================================== --- trunk/src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c	(working copy) @@ -1454,6 +1454,31 @@ } +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +#if RTLNX_VER_MIN(5,18,0) +    kernel_fpu_begin(); +    /* if (fCtxHook) */ +        preempt_enable();  /* HACK ALERT! undo the implicit preempt_disable() in kernel_fpu_begin(). */ +    return true; +#else +    return false; +#endif +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +#if RTLNX_VER_MIN(5,18,0) +    /* if (fCtxHook) */ +        preempt_disable();  /* HACK ALERT! undo the implicit preempt_enable() in SUPR0FpuBegin(). */ +    kernel_fpu_end(); +#endif +} + + int VBOXCALL    supdrvOSGetCurrentGdtRw(RTHCUINTPTR *pGdtRw) { #if RTLNX_VER_MIN(4,12,0) Index: src/VBox/HostDrivers/Support/os2/SUPDrv-os2.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/os2/SUPDrv-os2.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/os2/SUPDrv-os2.cpp	(working copy) @@ -541,3 +541,16 @@ return 0; } + +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + Index: src/VBox/HostDrivers/Support/solaris/SUPDrv-solaris.c =================================================================== --- trunk/src/VBox/HostDrivers/Support/solaris/SUPDrv-solaris.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/solaris/SUPDrv-solaris.c	(working copy) @@ -1309,3 +1309,16 @@ return 0; } + +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + Index: src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp	(working copy) @@ -2704,6 +2704,19 @@ } +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + + SUPR0DECL(int) SUPR0IoCtlSetupForHandle(PSUPDRVSESSION pSession, intptr_t hHandle, uint32_t fFlags, PSUPR0IOCTLCTX *ppCtx) { /* Index: src/VBox/HostDrivers/VBoxNetFlt/linux/VBoxNetFlt-linux.c =================================================================== --- trunk/src/VBox/HostDrivers/VBoxNetFlt/linux/VBoxNetFlt-linux.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/VBoxNetFlt/linux/VBoxNetFlt-linux.c	(working copy) @@ -2311,7 +2311,13 @@ vboxNetFltDumpPacket(pSG, true, "host", (fDst & INTNETTRUNKDIR_WIRE) ? 0 : 1); Log6(("vboxNetFltPortOsXmit: pBuf->cb dump:n%.*Rhxdn", sizeof(pBuf->cb), pBuf->cb)); Log6(("vboxNetFltPortOsXmit: netif_rx_ni(%p)n", pBuf)); +#if RTLNX_VER_MIN(5,18,0) +                local_bh_disable(); +                err = netif_rx(pBuf); +                local_bh_enable(); +#else err = netif_rx_ni(pBuf); +#endif if (err) rc = RTErrConvertFromErrno(err); } Index: src/VBox/VMM/VMMR0/CPUMR0.cpp =================================================================== --- trunk/src/VBox/VMM/VMMR0/CPUMR0.cpp	(revision 151556) +++ trunk/src/VBox/VMM/VMMR0/CPUMR0.cpp	(working copy) @@ -440,6 +440,9 @@ Assert(!(pVCpu->cpum.s.fUseFlags & CPUM_USED_FPU_GUEST)); Assert(!(pVCpu->cpum.s.fUseFlags & CPUM_SYNC_FPU_STATE)); +    /* Notify the support driver prior to loading the guest-FPU register state. */ +    SUPR0FpuBegin(false /* unused */); + if (!pVM->cpum.s.HostFeatures.fLeakyFxSR) { Assert(!(pVCpu->cpum.s.fUseFlags & CPUM_USED_MANUAL_XMM_RESTORE)); @@ -484,6 +487,9 @@ Assert(ASMGetCR4() & X86_CR4_OSFXSR); if (pVCpu->cpum.s.fUseFlags & (CPUM_USED_FPU_GUEST | CPUM_USED_FPU_HOST)) { +        /* Notify the support driver prior to loading the host-FPU register state. */ +        SUPR0FpuEnd(false /* unused */); + fSavedGuest = RT_BOOL(pVCpu->cpum.s.fUseFlags & CPUM_USED_FPU_GUEST); if (!(pVCpu->cpum.s.fUseFlags & CPUM_USED_MANUAL_XMM_RESTORE)) cpumR0SaveGuestRestoreHostFPUState(&pVCpu->cpum.s); </del>

I observed the bug on three different machines (two desktop machines with NixOS 22.05 and NixOS 21.11, and one laptop with NixOS 21.11). I was also able to reproduce the bug with a linux live cd inside the guest. So the bug can probably be triggered by any linux in the guest. I haven't, however, tried with anything else (e.g. Windows). I was also able to reproduce the bug with a live iso based on (currently ), i.e., with virtualbox 6.1.30 (as opposed to virtualbox 6.1.34 from , currently ). By default, the virtual disk controller has it's checkmark "Use Host I/O cache" turned off in the vm config dialog. Turning it on doesn't help (). I cannot reproduce the bug with these linux kernel versions (all checked with current ) (4.19.247) (5.4.198) (5.18.4) So users of these kernel branches are safe ... until the breaking kernel patch also reaches these branches. <details<summaryFor the record: This is the build recipe I'm using for the live iso</summary<p</p</detailsMaybe I can try to bisect inside the kernel sources, but the compile-reboot-test cycle is quite slow on my machine. Strangely, I cannot find any reports about similar behaviour. The closest report might be . It would be interesting for me if this bug can be reproduced/verified by someone else. I'm not sure if this should be considered a kernel bug (the kernel should probably not change the way disk writes are handled), or a virtualbox bug (at the moment I don't know of any other software affected). kernel maintainer team: virtualbox maintainer: (by the way: I'm surprised there's only one maintainer for virtualbox. Thanks for your good work, ; I'm a heavy user!) This is my production system, which also shows that bug. But I did most of the tests to reproduce the bug and narrow down the cause with live iso images based on current ().
I bisected the linux kernel tree to find as the cause for the guest data corruption. Googling the commit's hash leads to this issue in the VirtualBox bug tracker.


Question: <del> Index: include/VBox/sup.h =================================================================== --- trunk/include/VBox/sup.h	(revision 151556) +++ trunk/include/VBox/sup.h	(working copy) @@ -2142,6 +2142,26 @@ */ SUPR0DECL(uint32_t) SUPR0GetKernelFeatures(void); +/** + * Notification from R0 VMM prior to loading the guest-FPU register state. + * + * @returns Whether the host-FPU register state has been saved by the host kernel. + * @param   fCtxHook    Whether thread-context hooks are enabled. + * + * @remarks Called with preemption disabled. + */ +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook); + +/** + * Notification from R0 VMM prior to saving the guest-FPU register state (and + * potentially restoring the host-FPU register state) in ring-0. + * + * @param   fCtxHook    Whether thread-context hooks are enabled. + * + * @remarks Called with preemption disabled. + */ +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook); + /** @copydoc RTLogGetDefaultInstanceEx * @remarks To allow overriding RTLogGetDefaultInstanceEx locally. */ SUPR0DECL(struct RTLOGGER *) SUPR0GetDefaultLogInstanceEx(uint32_t fFlagsAndGroup); Index: src/VBox/Additions/linux/sharedfolders/regops.c =================================================================== --- trunk/src/VBox/Additions/linux/sharedfolders/regops.c	(revision 151556) +++ trunk/src/VBox/Additions/linux/sharedfolders/regops.c	(working copy) @@ -3823,7 +3823,9 @@ .readpage       = vbsf_readpage, .writepage      = vbsf_writepage, /** @todo Need .writepages if we want msync performance...  */ -#if RTLNX_VER_MIN(2,5,12) +#if RTLNX_VER_MIN(5,18,0) +    .dirty_folio = filemap_dirty_folio, +#elif RTLNX_VER_MIN(2,5,12) .set_page_dirty = __set_page_dirty_buffers, #endif #if RTLNX_VER_MIN(5,14,0) Index: src/VBox/Additions =================================================================== --- trunk/src/VBox/Additions	(revision 151556) +++ trunk/src/VBox/Additions	(working copy) Property changes on: src/VBox/Additions ___________________________________________________________________ Modified: svn:mergeinfo ## -0,0 +0,1 ## Merged /trunk/src/VBox/Additions:r150844 Index: src/VBox/HostDrivers/Support/SUPDrv.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/SUPDrv.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/SUPDrv.cpp	(working copy) @@ -98,6 +98,18 @@ # endif #endif +#if defined(RT_OS_LINUX) && !defined(__NO_FORTIFY) && defined(__OPTIMIZE__) && defined(CONFIG_FORTIFY_SOURCE) +/* In Linux 5.18-rc1, memcpy became a wrapper which does fortify checks + * before triggering __underlying_memcpy() call. We do not pass these checks here, + * so bypass them for now.  */ +# if RTLNX_VER_MIN(5,18,0) +#  define SUPDRV_MEMCPY __underlying_memcpy +# else +# define SUPDRV_MEMCPY  memcpy +# endif +#else +# define SUPDRV_MEMCPY  memcpy +#endif /* * Logging assignments: @@ -266,6 +278,8 @@ SUPEXP_STK_BACK(    2,  SUPR0ContFree), SUPEXP_STK_BACK(    2,  SUPR0ChangeCR4), SUPEXP_STK_BACK(    1,  SUPR0EnableVTx), +    SUPEXP_STK_OKAY(    1,  SUPR0FpuBegin), +    SUPEXP_STK_OKAY(    1,  SUPR0FpuEnd), SUPEXP_STK_BACK(    0,  SUPR0SuspendVTxOnCpu), SUPEXP_STK_BACK(    1,  SUPR0ResumeVTxOnCpu), SUPEXP_STK_OKAY(    1,  SUPR0GetCurrentGdtRw), @@ -1742,7 +1756,7 @@ /* execute */ pReq->u.Out.cFunctions = RT_ELEMENTS(g_aFunctions); -            memcpy(&pReq->u.Out.aFunctions[0], g_aFunctions, sizeof(g_aFunctions)); +            SUPDRV_MEMCPY(&pReq->u.Out.aFunctions[0], g_aFunctions, sizeof(g_aFunctions)); pReq->Hdr.rc = VINF_SUCCESS; return 0; } Index: src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp	(working copy) @@ -2002,6 +2002,18 @@ } +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + /* * * org_virtualbox_SupDrv Index: src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c =================================================================== --- trunk/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c	(working copy) @@ -640,3 +640,16 @@ return 0; } + +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + Index: src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c =================================================================== --- trunk/src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c	(working copy) @@ -1454,6 +1454,31 @@ } +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +#if RTLNX_VER_MIN(5,18,0) +    kernel_fpu_begin(); +    /* if (fCtxHook) */ +        preempt_enable();  /* HACK ALERT! undo the implicit preempt_disable() in kernel_fpu_begin(). */ +    return true; +#else +    return false; +#endif +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +#if RTLNX_VER_MIN(5,18,0) +    /* if (fCtxHook) */ +        preempt_disable();  /* HACK ALERT! undo the implicit preempt_enable() in SUPR0FpuBegin(). */ +    kernel_fpu_end(); +#endif +} + + int VBOXCALL    supdrvOSGetCurrentGdtRw(RTHCUINTPTR *pGdtRw) { #if RTLNX_VER_MIN(4,12,0) Index: src/VBox/HostDrivers/Support/os2/SUPDrv-os2.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/os2/SUPDrv-os2.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/os2/SUPDrv-os2.cpp	(working copy) @@ -541,3 +541,16 @@ return 0; } + +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + Index: src/VBox/HostDrivers/Support/solaris/SUPDrv-solaris.c =================================================================== --- trunk/src/VBox/HostDrivers/Support/solaris/SUPDrv-solaris.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/solaris/SUPDrv-solaris.c	(working copy) @@ -1309,3 +1309,16 @@ return 0; } + +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + Index: src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp =================================================================== --- trunk/src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp	(revision 151556) +++ trunk/src/VBox/HostDrivers/Support/win/SUPDrv-win.cpp	(working copy) @@ -2704,6 +2704,19 @@ } +SUPR0DECL(bool) SUPR0FpuBegin(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +    return false; +} + + +SUPR0DECL(void) SUPR0FpuEnd(bool fCtxHook) +{ +    RT_NOREF(fCtxHook); +} + + SUPR0DECL(int) SUPR0IoCtlSetupForHandle(PSUPDRVSESSION pSession, intptr_t hHandle, uint32_t fFlags, PSUPR0IOCTLCTX *ppCtx) { /* Index: src/VBox/HostDrivers/VBoxNetFlt/linux/VBoxNetFlt-linux.c =================================================================== --- trunk/src/VBox/HostDrivers/VBoxNetFlt/linux/VBoxNetFlt-linux.c	(revision 151556) +++ trunk/src/VBox/HostDrivers/VBoxNetFlt/linux/VBoxNetFlt-linux.c	(working copy) @@ -2311,7 +2311,13 @@ vboxNetFltDumpPacket(pSG, true, "host", (fDst & INTNETTRUNKDIR_WIRE) ? 0 : 1); Log6(("vboxNetFltPortOsXmit: pBuf->cb dump:n%.*Rhxdn", sizeof(pBuf->cb), pBuf->cb)); Log6(("vboxNetFltPortOsXmit: netif_rx_ni(%p)n", pBuf)); +#if RTLNX_VER_MIN(5,18,0) +                local_bh_disable(); +                err = netif_rx(pBuf); +                local_bh_enable(); +#else err = netif_rx_ni(pBuf); +#endif if (err) rc = RTErrConvertFromErrno(err); } Index: src/VBox/VMM/VMMR0/CPUMR0.cpp =================================================================== --- trunk/src/VBox/VMM/VMMR0/CPUMR0.cpp	(revision 151556) +++ trunk/src/VBox/VMM/VMMR0/CPUMR0.cpp	(working copy) @@ -440,6 +440,9 @@ Assert(!(pVCpu->cpum.s.fUseFlags & CPUM_USED_FPU_GUEST)); Assert(!(pVCpu->cpum.s.fUseFlags & CPUM_SYNC_FPU_STATE)); +    /* Notify the support driver prior to loading the guest-FPU register state. */ +    SUPR0FpuBegin(false /* unused */); + if (!pVM->cpum.s.HostFeatures.fLeakyFxSR) { Assert(!(pVCpu->cpum.s.fUseFlags & CPUM_USED_MANUAL_XMM_RESTORE)); @@ -484,6 +487,9 @@ Assert(ASMGetCR4() & X86_CR4_OSFXSR); if (pVCpu->cpum.s.fUseFlags & (CPUM_USED_FPU_GUEST | CPUM_USED_FPU_HOST)) { +        /* Notify the support driver prior to loading the host-FPU register state. */ +        SUPR0FpuEnd(false /* unused */); + fSavedGuest = RT_BOOL(pVCpu->cpum.s.fUseFlags & CPUM_USED_FPU_GUEST); if (!(pVCpu->cpum.s.fUseFlags & CPUM_USED_MANUAL_XMM_RESTORE)) cpumR0SaveGuestRestoreHostFPUState(&pVCpu->cpum.s); </del>

According to the information therein, the bug only occurs on some CPU models. The issue there also contains two patches: from This one fixes the problem on linux 5.18. It got already included in nixpkgs' master branch with . It is on it's way to being backported to NixOS 22.05 with . Note that this patch contains several clauses and does not fix the problem on earlier LTS kernel versions. from This one fixes the problem on linux 5.18+, but also on LTS kernel versions. I tested the following combinations with (currently on , where VirtualBox 6.1.34 with and linux 5.15.51 are used by default): VirtualBox version & patch 5.18.8 -----------------------------:------: 6.1.34 + OK 6.1.34 + OK I also tested the following combinations with (currently on , where VirtualBox 6.1.30 and linux 5.15.49 are used by default): VirtualBox version & patch 5.18.6 -----------------------------:------------: 6.1.30 won't build 6.1.34 + OK 6.1.34 + OK To replace VirtualBox 6.1.30 with 6.1.34, I cherry-picked . All tests have been performed on an Intel Core i5-4460 as host, by repeatedly writing/reading 4GiB of random data onto/from a virtual hard disk. Based on these tests, I suggest to use VirtualBox 6.1.34 with the in NixOS 22.05 and in NixOS unstable, as currently, both channels will exhibit the bug in their default configurations (i.e., with kernel 5.15). I will submit a pull request for master shortly.


Question: # tesseract & leptonica. ++ lib.optionals enableTesseract [ tesseract leptonica ] ++ lib.optional enableTbb tbb <del> ++ lib.optionals enableCuda [ cudatoolkit nvidia-optical-flow-sdk ] </del> ++ lib.optionals stdenv.isDarwin [ bzip2 AVFoundation Cocoa VideoDecodeAcceleration CoreMedia MediaToolbox ] ++ lib.optionals enableDocs [ doxygen graphviz-nox ]; <del> propagatedBuildInputs = lib.optional enablePython pythonPackages.numpy; </del> <ins> propagatedBuildInputs = lib.optional enablePython pythonPackages.numpy ++ lib.optionals enableCuda [ cudatoolkit nvidia-optical-flow-sdk ]; </ins> nativeBuildInputs = [ cmake pkg-config unzip ];

qimgv fails to build when . Steps to reproduce the behavior: No build errors. N/A. N/A. Maintainer information:
I am working on a patch to OpenCV to fix this issue correctly. In the meantime, you can replace with and it will build and operate properly. On my system I also had to add to to stop it crashing when I tried to open a file dialog but maybe that is just because I run Nix on Ubuntu instead of NixOS.


Question: description = "Twitch.tv browser for Streamlink"; longDescription = "Browse Twitch.tv and watch streams in your videoplayer of choice"; homepage = "https://streamlink.github.io/streamlink-twitch-gui/"; <del> downloadPage = https://github.com/streamlink/streamlink-twitch-gui/releases; </del> <ins> downloadPage = "https://github.com/streamlink/streamlink-twitch-gui/releases"; </ins> license = licenses.mit; maintainers = with maintainers; [ rileyinman ]; platforms = [ "x86_64-linux" "i686-linux" ];

Cannot view any content when running the program because it complains about missing binaries. Steps to reproduce the behavior: to watch any stream No errors, stream works system: host os: multi-user?: sandbox: version: channels(admin): nixpkgs: Add and as runtime dependencies because the following works for me:


Question: module_init_tools = kmod; # added 2016-04-22 mozart = mozart2-binary; # added 2019-09-23 mozart-binary = mozart2-binary; # added 2019-09-23 <ins> mpc_cli = mpc-cli; # moved from top-level 2022-01-24 </ins> mpd_clientlib = libmpdclient; # added 2021-02-11 mpich2 = mpich;  # added 2018-08-06 msf = metasploit; # added 2018-04-25

The mpccli package is missing bashcompletion, even though a bash completion file is in the upstream repo under contrib/mpc- . Steps to reproduce the behavior: the package a terminal and type It tries only to complete with the contents of the current directory mpc should be completed with the mpc subcomands like , , etc. On a regular system, the file would have to be installed under /etc/bashcompletion.d/ . I don't know whats the nix(os) equivalent to this.
First, I am not the maintainer of this package. Nonetheless I will review this. Second, in Nixpkgs we do "almost" the same: we use a special hook that installs those extra files at the . Now I need to sleep; please wait a bit more.


Question: gcr gnome.adwaita-icon-theme libsecret <ins> libportal-gtk3 </ins> ]; postPatch = ''

Steps to reproduce the behavior: shotwell from latest nixos-unstable I simply install shotwell with . Noticed that often updates this derivation, last time it was changed by but I don't think his change would cause this. Otherwise - meta.maintainers is empty. Please run and paste the result.


Question: <del> { stdenv, fetchFromGitHub, autoconf, automake, libtool, ... }: </del> <ins> { stdenv, fetchFromGitHub, autoreconfHook, jdk # Enable ECDSA pubkey recovery module , enableRecovery ? true # Enable ECDH shared secret computation (disabled by default because it is # experimental) , enableECDH ? false # Enable libsecp256k1_jni (disabled by default because it requires a jdk, # which is a large dependency) , enableJNI ? false }: let inherit (stdenv.lib) optionals; in </ins> stdenv.mkDerivation rec { name = "secp256k1-${version}"; <del> # I can't find any version numbers, so we're just using the date # of the last commit. version = "2016-05-30"; </del> <ins> # I can't find any version numbers, so we're just using the date of the # last commit. version = "2016-11-27"; </ins> src = fetchFromGitHub { owner = "bitcoin-core"; repo = "secp256k1"; <del> rev = "b3be8521e694eaf45dd29baea035055183c42fe2"; sha256 = "1pgsy72w87yxbiqn96hnm8alsfx3rj7d9jlzdsypyf6i1rf6w4bq"; </del> <ins> rev = "2928420c1b8e1feee8c20dff4e3cc41a0de2fc22"; sha256 = "1djsr2vrhh88353czlwb8bwlyabf008w1f7xg0fs3q33rf42w5gm"; </ins> }; <del> buildInputs = [ autoconf automake libtool ]; </del> <ins> buildInputs = optionals enableJNI [ jdk ]; </ins> <del> configureFlags = [ "--enable-module-recovery" ]; </del> <ins> nativeBuildInputs = [ autoreconfHook ]; </ins> <del> preConfigure = "./autogen.sh"; </del> <ins> configureFlags = optionals enableECDH [ "--enable-module-ecdh" "--enable-experimental" ] ++ optionals enableRecovery [ "--enable-module-recovery" ] ++ optionals enableJNI [ "--enable-jni" ]; </ins> meta = with stdenv.lib; { description = "Optimized C library for EC operations on curve secp256k1"; longDescription = '' <del> Optimized C library for EC operations on curve secp256k1. Part of Bitcoin Core. This library is a work in progress and is being used to research best practices. Use at your own risk. </del> <ins> Optimized C library for EC operations on curve secp256k1. Part of Bitcoin Core. This library is a work in progress and is being used to research best practices. Use at your own risk. </ins> ''; homepage = https://github.com/bitcoin-core/secp256k1; license = with licenses; [ mit ];

There are a few more flags we should enable on : - (I had to add these flags for the sake of something that depends on secp256k1 - I don't remember for sure, but I think it's bitcoinj.)
The schnorr flag appears to be gone in the latest version.


Question: (fetchNuGet { pname = "ppy.Veldrid.MetalBindings"; version = "4.9.5-gc8dfc5ca19"; sha256 = "0i6bb79kprrmsfphjq26rgxqfvvf12pxr7dfwcq448dw2xgq6rpy"; }) (fetchNuGet { pname = "ppy.Veldrid.OpenGLBindings"; version = "4.9.5-gc8dfc5ca19"; sha256 = "06a4kkfidr7yj60xl3k4yfawz4wzwkkjpaki8fmsanif1yhz69l8"; }) (fetchNuGet { pname = "ppy.Veldrid.SPIRV"; version = "1.0.15-gca6cec7843"; sha256 = "09pi4c91ljavilw9kx7kzhcax7ar4zk7zy1qwvqfrqsgxznvyxa1"; }) <del> (fetchNuGet { pname = "Realm"; version = "11.7.0"; sha256 = "1vp8rparpcv7rbqx7m55xcji941a6qjamxhb943fgfkjf196z69w"; }) (fetchNuGet { pname = "Realm.PlatformHelpers"; version = "11.7.0"; sha256 = "1a7kaap5ad3n7cgf07xa9yc4c1qi7cf2zj3f5hdv7fp84bdzmysg"; }) </del> <ins> (fetchNuGet { pname = "Realm"; version = "11.5.0"; sha256 = "0r7j5si3n4ncq8xnnjk1q5jjqbj0s1w3ps124y8pgqd14dzvch6a"; }) (fetchNuGet { pname = "Realm.PlatformHelpers"; version = "11.5.0"; sha256 = "1ggbmlsf04pxnh1k86hs0wxnvcw0ja2xnn6358qmrp826km0w1g9"; }) </ins> (fetchNuGet { pname = "Remotion.Linq"; version = "2.2.0"; sha256 = "1y46ni0xswmmiryp8sydjgryafwn458dr91f9xn653w73kdyk4xf"; }) (fetchNuGet { pname = "runtime.any.System.Collections"; version = "4.3.0"; sha256 = "0bv5qgm6vr47ynxqbnkc7i797fdi8gbjjxii173syrx14nmrkwg0"; }) (fetchNuGet { pname = "runtime.any.System.Diagnostics.Tools"; version = "4.3.0"; sha256 = "1wl76vk12zhdh66vmagni66h5xbhgqq7zkdpgw21jhxhvlbcl8pk"; })

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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: rustPlatform.buildRustPackage rec { pname = "gping"; <del> version = "1.2.1"; </del> <ins> version = "1.2.6"; </ins> src = fetchFromGitHub { owner = "orf"; repo = "gping"; <del> rev = "v${version}"; sha256 = "sha256-lApm1JLXNjDKLj6zj25OaZDVp7lLW3qyrDsvJrudl8I="; </del> <ins> rev = "gping-v${version}"; sha256 = "sha256-Sxmwuf+iTBTlpfMFCEUp6JyEaoHgmLIKB/gws2KY/xc="; </ins> }; <del> cargoSha256 = "sha256-d1NjPwT3YDp1U9JWeUejpWDbJonFlt5lYbUf7p3jVT0="; </del> <ins> cargoSha256 = "sha256-xEASs6r5zxYJXS+at6aX5n0whGp5qwuNwq6Jh0GM+/4="; </ins> buildInputs = lib.optional stdenv.isDarwin libiconv;

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


Question: <ins> { rustPlatform, lib, fetchFromGitHub, nix-update-script, nixosTests, }: rustPlatform.buildRustPackage rec { pname = "turn-rs"; version = "3.1.0"; src = fetchFromGitHub { owner = "mycrl"; repo = "turn-rs"; rev = "refs/tags/v${version}"; hash = "sha256-uXMRDgSHrwT6+kejWRSE1WjXO8LaOR+fnffIXcL3A4I="; }; cargoHash = "sha256-gO2vuOQMvl6KYp529k3CYDyma5ECzOr/lcSvP4OpUUo="; passthru = { updateScript = nix-update-script { }; tests.nixos = nixosTests.turn-rs; }; meta = { description = "Pure rust implemented turn server"; homepage = "https://github.com/mycrl/turn-rs"; changelog = "https://github.com/mycrl/turn-rs/releases/tag/v${version}"; license = lib.licenses.gpl3Only; mainProgram = "turn-server"; maintainers = with lib.maintainers; [ bot-wxt1221 ]; platforms = lib.platforms.linux; }; } </ins>

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


Question: { lib , stdenv <del> , fetchFromGitHub </del> <ins> , fetchFromGitea , substituteAll </ins> , testers , gummy , cmake

Package name: gummy Latest released version: 0.6.0 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- There is an open pull request () by from October 2023, but it has not been merged and later versions of the program have been released since then. I think it is also worth noting that the source code repository of the is no longer available on GitHub. as the repository has moved to Codeberg (see ). Notify maintainers (last updated the package) <!-- 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]:
I updated my linked PR to the latest version.
Thank you for updating it so quickly! Is there a time frame in which we can expect the pull request to be merged by someone?


Question: { lib , stdenv <del> , fetchFromGitHub </del> <ins> , fetchFromGitea , substituteAll </ins> , testers , gummy , cmake

Package name: gummy Latest released version: 0.5.4 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers I've tried to bump the version to 0.5.4. <details<summaryThe build fails when downloading json-poputlate</summary</details<!-- If the result shows no maintainers, tag the person that last updated the package. --


Question: <ins> { fetchFromGitHub, }: { qmplay2 = let self = { pname = "qmplay2"; version = "24.06.16"; src = fetchFromGitHub { owner = "zaps166"; repo = "QMPlay2"; rev = self.version; hash = "sha256-HoFyC/OFmthUYfyo6//+KmBIq06MPb5GmDekJbnsz5o="; }; }; in self; qmvk = { pname = "qmvk"; version = "0-unstable-2024-04-19"; src = fetchFromGitHub { owner = "zaps166"; repo = "QmVk"; rev = "5c5c2942255820b6343afdfeea0405cd3b36870e"; hash = "sha256-viFM9N5PiSCgkGlxtrLFCVDIML/QyPiaPRX77RW2NNw="; }; }; } </ins>

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.


Question: } <ins> sub cpuManufacturer { my $id = shift; return $cpuinfo =~ /^vendor_ids*:.* $id$/m; } </ins> # Determine CPU governor to use if (-e "/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors") {

It would be nice if generated and options (only ). Processors without microcode update might run with misbehaving flashed microcode: /cc
Do you mean like setting it to or just mentioning it? It's a good thing for sure to have working hardware as opposed to not working, but OTOH it pulls non free code...
Of course setting it to true (actually to ), mentioning it would have no effect. First, already pulls in literal unfree code, e.g. Wi-Fi drivers on MacBook Air 6,x, not even redistributable. Second, non-free code is already running on Intel processors, I don't see any difference whether it's flashed or not (I know this is controversial). Third, for purposes of Nixpkgs, is free. And of course the kernel contains a whole lot of firmware blobs.
Strongly disagree here as its an equivalent of setting = true; thus will taint every installation by default, which is a reverse policy of the current nixos from optin to optout. That said, being complete new user, I have myself figured and found these options myself. My system booted without them likewise fine. In general, AMD patches CPUs with AGEISA BIOS updates, so does Intel - however these updates are optional and up to the user. This is should be mentioned on a) Installation page b) NIxos wiki - not be made default option, because this action is in conflict with policy.
I disagree that this is equivalent. CPU comes preflashed with microcode, BIOS comes with updated microcode for the processor to boot correctly (microcode that comes with CPU is very buggy and usually can't go through boot sequence correctly). It's not clear how it would add to the problem if we were to load an up-to-date microcode image. This is equivalent to shipping firmware to users that haven't set flag, which is current NixOS policy. Intel microcode is freely redistributable AFAIK.
The default state for these two switches is very clearly "disabled", plus they have no affect on non-AMD/intel CPUs. Flipping the switch in hardware-, is basically flipping the default state in the backstage, which is much worse than setting the defaults to "enabled", as it creates distrust and inconsistency cases. Further, firmware updates can cause real issues, not only solve them.


Question: } <ins> sub cpuManufacturer { my $id = shift; return $cpuinfo =~ /^vendor_ids*:.* $id$/m; } </ins> # Determine CPU governor to use if (-e "/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors") {

It is irresponsible to think that they only solve issues. AMD AGEISA updates on 785G on has actually been broken for over a year for me, refusing to react to USB events on boot until I manually bypassed the tier 1&2 support (which is hell of a job for Linux user) to get to actual support for testing. About Intel, I have only encountered issues with gen3 PCIe cards in Intel motherboard for 2nd gen Core CPUs, but fixing this also required a year of waiting and UEFI reflash. Also speaking as an owner of HP() and Epson(sx525wd) printers - updating ucode actually caused hardware reflash and made legally purchased cartridges worthless. I am yet to encounter a CPU that can't pass boot sequence due to buggy ucode, but I doubt hot-loading it on OS stage would fix it, because it needs first to get to this stage. However I can clearly imagine the unpredictability if these switches are properly enabled.
Microcode is essentially a firmware for the CPU. NixOS, more specifically, the Linux kernel, will load firmwares for any device with support for that without asking the user. Loading microcode updates does not require a policy change, if anything, this would make the policy more consistent across the board. On a tangent, I don't understand why anyone would tolerate a blob flashed on CPU, and in BIOS, but would not tolerate the same blob being loaded by the kernel. That can be said about any software. Usually, the opposite is true. What I mean is that every BIOS except Libreboot contains microcode blobs that it loads onto the processor early in the boot sequence. Without that blob, boot sequence will most likely fail somewhere along the way. That's the reason why Libreboot doesn't support modern Intel/AMD CPUs, and why there is Coreboot/Libreboot split in the first place.
You are mixing very different cases into one bottle. Some hardware requires ucode to be loaded to function and won't function without. Some hardware has optional ucode updates. For this hardware, some classes load firmware update and then flash themselves - some lock the possibility to install previous revision, and some classes load the ucode as temporary override (which is case with AMD/Intel). Some hardware has open firmware (sources), but majority does not offer source.


Question: } <ins> sub cpuManufacturer { my $id = shift; return $cpuinfo =~ /^vendor_ids*:.* $id$/m; } </ins> # Determine CPU governor to use if (-e "/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors") {

In essence, ucode is a blackbox and live-updating ucode is unpredictable black box. For some devices, ucode loading is a must, for others its optional. I suggest that we limit ourselves to specific case of Intel/AMD ucode, for which ucode updates are optional and crucial updates are applied only via hardware flashing. I am pretty sure that the reason why Libreboot supports less hardware has to do purely with acceptance criteria for how tainted ("blackboxed") the firmware is, and that both support little of x86, because Intel refused to provide specifications and AMD was open to some extent, but then closed up the AGESA after Phenom II because they most possibly implemented TPM in firmware(fTPM). About EULA-d + encrypted software, we are talking about closed-source hardware. For manufacturers of such software, surely opposite is true and the updates are usually used to keep their policy consistent and enforced, for users it means giving up and restricting all rights. That said, I found those options myself easily as a new user (yet my hardware functioned without issues without them) and I see a problem if they default to one value, but change "automatically" and unnoticed at run-time. Either way, this option should be documented better - and this includes places where its flipped.
It's not clear what difference does it make. Say, from freedom perspective, it would not be OK to use Windows even if I were to ignore any updates for it. If we ship updated microcode, which includes security fixes foremost, how would that taint installs any more than they currently are, with in-kernel blobs and such?
It has to do with blobs for the most part. See:
It replaces non-free code with a more up2date non-free code. Given Meltdown and Spectre this should be the default. Especially since it would be generated at installation time. Accompanied with the right comment, users who really want to have outdated CPUs will be notified and can delete one line. (well two with the comment).
I would like this to default to (microcode essentially is firmware). isn't supposed to be edited, it should just use so that user can override it in their config.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days.


Question: } <ins> sub cpuManufacturer { my $id = shift; return $cpuinfo =~ /^vendor_ids*:.* $id$/m; } </ins> # Determine CPU governor to use if (-e "/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors") {

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 . on the on .
still think this should be done, as new users probably don't know this option exists at all and that you have to enable it by yourself in NixOS. With concerns on, this should at least be generated as commented out, with a hint "while you will probably want this, note that it is unfree software".
I marked this as stale due to inactivity. →
Why is this no longer in discussion? As someone new to the NixOS universe and coming from Ubuntu I wasn't aware that I had to explicitely include this in my hardware configuration on NixOS until I stumbled across other people's configuration files. I definitely think it should at least be prominently featured in the installation manual or even better be enabled by default, as mentioned.
One way or another, needs to be enabled by default. These updates fix security issues, there are probably a lot of NixOS users now that don't even know that they're running insecure microcode. See also the discussion in
I've never replied to the first comment! While I still support the open hardware movement (and thus free software firmware) I also believe that having QEMU misbehave because of a missing update is not really a good default option. If the user is concerned about the microcode updates or about managing security at this level then they will probably read the auto-generated configuration and immediately spot an and will comment it out :-) So thanks for the PR, I can't review because I don't know perl :-p


Question: { lib, fetchFromGitHub, cmake, curl, xorg, avahi, qtbase, mkDerivation, openssl, wrapGAppsHook, <del> avahiWithLibdnssdCompat ? avahi.override { withLibdnssdCompat = true; } </del> <ins> avahiWithLibdnssdCompat ? avahi.override { withLibdnssdCompat = true; }, fetchpatch </ins> }: mkDerivation rec {

The package is failing to build Steps to reproduce the behavior: The package to build successfully without errors
I'm sorry, I haven't used in years - but also nothing with that package has changed in some while. I'd assume an upstream problem?
I don't use but took a look out of curiosity. It was an upstream problem that is fixed by a few commits after the latest 2.4.0 release. There hasn't been a new release since then. Is the best thing to do here pull down that commit as an isolated patch or to bump the revision that's pulled down to that (untagged) revision?
Can we use in the meantime?


Question: if ($copyKernels == 0) { $grubStore = GrubFs($storePath); } <del> my $extraInitrdPath; if ($extraInitrd) { if (! -f $extraInitrd) { print STDERR "Warning: the specified extraInitrd " . $extraInitrd . " doesn't exist. Your system won't boot without it.n"; } $extraInitrdPath = GrubFs($extraInitrd); } </del> # Generate the header. my $conf .= "# Automatically generated.  DO NOT EDIT THIS FILE!n";

Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.


Question: <ins> Fetched from https://blog.sonarsource.com/rainloop-emails-at-risk-due-to-code-flaw/ --- a/rainloop/rainloop/v/1.16.0/app/libraries/MailSo/Base/HtmlUtils.php +++ b/rainloop/rainloop/v/1.16.0/app/libraries/MailSo/Base/HtmlUtils.php @@ -239,7 +239,8 @@ class HtmlUtils $oWrapHtml->setAttribute($sKey, $sValue); } -			$oWrapDom = $oDom->createElement('div', '___xxx___'); +			$rand_str = base64_encode(random_bytes(32)); +			$oWrapDom = $oDom->createElement('div', $rand_str); $oWrapDom->setAttribute('data-x-div-type', 'body'); foreach ($aBodylAttrs as $sKey => $sValue) { @@ -250,7 +251,7 @@ class HtmlUtils $sWrp = $oDom->saveHTML($oWrapHtml); -			$sResult = str_replace('___xxx___', $sResult, $sWrp); +			$sResult = str_replace($rand_str, $sResult, $sWrp); } $sResult = str_replace(MailSoBaseHtmlUtils::$KOS, ':', $sResult); </ins>

via In short: rainloop, a php-based webmail client, features a trivially exploitable stored xss vulnerability. Upstream is unresponsive, and seem to have ceased development. This page explains how the XSS works and proposes an unofficial patch: Example of an other distro applying this very patch:


Question: stable = mkFlutter { pname = "flutter"; channel = "stable"; <del> version = "1.12.13+hotfix.8"; sha256Hash = "01ik4xckr3fp65sq4g0g6wy5b9i0r49l643xmbxa6z9k21sby46d"; </del> <ins> version = "1.12.13+hotfix.9"; sha256Hash = "1ql3zvmmk5zk47y30lajxaam04q6vr373dayq15jv4vpc0fzif1y"; </ins> patches = getPatches ./patches/stable; }; beta = mkFlutter { pname = "flutter-beta"; channel = "beta"; <del> version = "1.14.6"; sha256Hash = "1a79pr741zkr39p5gc3p9x59d70vm60hpz2crgc53ysglj4ycigy"; </del> <ins> version = "1.15.17"; sha256Hash = "0iil6y6y477dhjgzx54ab5m9nj0jg4xl8x4zzd9iwh8m756r7qsd"; </ins> patches = getPatches ./patches/beta; }; <del> dev = mkFlutter { </del> <ins> dev = mkFlutter rec { </ins> pname = "flutter-dev"; channel = "dev"; <del> version = "1.15.3"; sha256Hash = "06mawwqf7q7wdmzlyxlrlblhnnk4ckf3vp92lplippdh3d52r93i"; patches = getPatches ./patches/dev; </del> <ins> version = "1.17.0-dev.5.0"; filename = "flutter_linux_${version}-${channel}.tar.xz"; sha256Hash = "0ks2jf2bd42y2jsc91p33r57q7j3m94d8ihkmlxzwi53x1mwp0pk"; patches = getPatches ./patches/beta; </ins> }; }

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


Question: # Give key acme permissions chown '${data.user}:${data.group}' "${apath}/"{key,fullchain,full}.pem <del> chmod ${rights} "${apath}/"{key,fullchain,full}.pem </del> <ins> chmod ${fileMode} "${apath}/"{key,fullchain,full}.pem </ins> ''; serviceConfig = { Type = "oneshot";

Describe the bug If I change and enable when the cert/key in question already exists the group access will not be granted after rebuilding and restarting the . This is because a condition in the post start script does so only when the key is newer than the existing one. To Reproduce Steps to reproduce the behavior: without group/allowKeysForGroup and start the service to reques the certificate group and allowKeysForGroup again and restart the service, the ownership/ode will not be updated Expected behavior The group and chmod setting should be set on existing certificates as well as new ones. Metadata Please run and paste the result. Maintainer information:
Additionally, shouldn't chmod 0640 suffice on the files?
cc as potentially interested individuals


Question: python3Packages.buildPythonApplication rec { pname = "keepmenu"; <del> version = "1.2.2"; </del> <ins> version = "1.3.1"; </ins> src = fetchPypi { inherit pname version; <del> sha256 = "SeVNtONH1bn2hb2pBOVM3Oafrb+jARgfvRe7vUu6Gto="; </del> <ins> hash = "sha256-AGuJY7IirzIjcu/nY9CzeOqU1liwcRijYLi8hGN/pRg="; </ins> }; preConfigure = ''

Package name: keepmenu Latest released version: 1.3.1 Current version on the unstable channel: 1.2.2 Current version on the stable/release channel: 1.2.2 Notify maintainers Note for maintainers: Please tag this issue in your PR.


Question: oldInterpreterLine=$(head -1 "$f" | tail -c+3) read -r oldPath arg0 args <<< "$oldInterpreterLine" <ins> if [ -z "$pathName" ]; then if [ -n "$strictDeps" ] && [[ "$f" = "$NIX_STORE"* ]]; then pathName=HOST_PATH else pathName=PATH fi fi </ins> if $(echo "$oldPath" | grep -q "/bin/env$"); then # Check for unsupported 'env' functionality: # - options: something starting with a '-'

uses to determine the substitute for the shebang path. This selects the wrong path during cross-builds and results in x8664 binaries getting pulled in as dependencies to cross-built binaries that can't possibly use them at runtime. I don't know if we can reliably pick the correct /bin/sh without it being in the PATH envvar. I presume patchShebangs works fine for binaries that don't overlap with stdenv's and are included in buildInputs. If you cross-build some packages to ARM platforms, patchShebangs runs in the fixup phase and run , you'll see it points to the native /bin/sh rather than the cross one. I was considering a PR to just add to the cross build of glibc, but figured it'd be better if the root issue were fixed instead. System: "16.03pre75806." Nix version: nix-env (Nix) 1.12pre1234abcdef Nixpkgs version: (Gorilla)
/participate. (I've stumbled across this too.)
Is it safe to assume are the only paths that will ever realistically have this problem? If so, how and where would we pull in as a buildInput without it clobbering the native /bin/sh used by stdenv to run the builder? Once we're already executing , it's too late to find any s. This problem overlaps with another, , which is that crossDrvs clobber stdenv's binaries in the PATH. The best solution I can come up with is to manually include in of e.g. glibc, add logic in to not add to the PATH when crossbuilding, based on some new derivation attr like , then search during , independently of what's set in the PATH. Or we could just make smarter about importing /bin/ PATHs that contain elements of the stdenv, namely: .
is essential to fix this without greatly complicating bootstrapping.
don't forget to close. :)
Addressed in


Question: let # Release calendar: https://www.mesa3d.org/release-calendar.html # Release frequency: https://www.mesa3d.org/releasing.html#schedule <del> version = "21.0.1"; </del> <ins> version = "21.0.3"; </ins> branch  = versions.major version; self = stdenv.mkDerivation {

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: # supporting it, or their bundled containerd systemd.enableUnifiedCgroupHierarchy = false; <ins> environment.systemPackages = [ config.services.k3s.package ]; </ins> systemd.services.k3s = { description = "k3s service"; after = mkIf cfg.docker [ "docker.service" ]; wantedBy = [ "multi-user.target" ]; <ins> path = optional config.boot.zfs.enabled config.boot.zfs.package; </ins> serviceConfig = { # See: https://github.com/rancher/k3s/blob/dddbd16305284ae4bd14c0aade892412310d7edc/install.sh#L197 Type = if cfg.role == "agent" then "exec" else "notify";

Describe the bug nixpkgs has moved to unified cgroups (woo :tada:) as of recently (). Unfortunately, k3s fails to start correctly with unified cgroups without , which isn't included in a release yet. Until that lands in a release and nixpkgs is updated, it can be worked around by setting I intend to work on fixing this; I'll drop any notes along the way in this issue.
I've updated the title to be more specific, since my actual errors are coming from using k3s with , and the error is specifically about kubelet and docker's cgroup driver mismatching. I see that the unified cgroup PR did disable unified cgroups in the k3s module, so that probably should work before adding in the docker runtime. I need to do a little more investigation here.
Please let me know, if this is related: I'm trying to follow the wiki article on kubernetes on nixos: With the configs shown there I run into an error when starting The full error is very long, I've uploaded it here:
Thanks for looking into this.
Just tried the workaround mentioned above: Setting also fixes the problem for the kubernetes service
We have observed that unified cgroups also breaks Kubernetes-in-Docker for node images prior to 1.19. The observed behavior is that the kubelet fails to start, with the message: Also able to work around with
For k3s, the v1.20.4+k3s1 release includes unified cgroups support. It fixes my use of k3s, though I also had to set a flag in the nixos module ( to make docker+kubelet match). I've opened up a PR to bump the package (), and I'll make a separate PR to fix the nixos module to pass that arg. I think those two changes together should fix this issue. It sounds like there's other work to be done for other ways of running kubernetes on nixos too, but I think we should open separate issues for those to avoid conflating too many issues at once.
This would be the fix: I was not invested enough at the time to also write release notes, but if you want you can pick up the change.
see
This PR should also help:
This issue has been mentioned on NixOS Discourse.


Question: # supporting it, or their bundled containerd systemd.enableUnifiedCgroupHierarchy = false; <ins> environment.systemPackages = [ config.services.k3s.package ]; </ins> systemd.services.k3s = { description = "k3s service"; after = mkIf cfg.docker [ "docker.service" ]; wantedBy = [ "multi-user.target" ]; <ins> path = optional config.boot.zfs.enabled config.boot.zfs.package; </ins> serviceConfig = { # See: https://github.com/rancher/k3s/blob/dddbd16305284ae4bd14c0aade892412310d7edc/install.sh#L197 Type = if cfg.role == "agent" then "exec" else "notify";

There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Question: checkFeatures = [ ]; patches = lib.optionals stdenv.isLinux [ <del> (runCommand "0001-dynamically-patchelf-binaries.patch" { CC = stdenv.cc; patchelf = patchelf; libPath = "$ORIGIN/../lib:${libPath}"; } '' </del> <ins> (runCommand "0001-dynamically-patchelf-binaries.patch" { CC = stdenv.cc; patchelf = patchelf; libPath = "${libPath}"; } '' </ins> export dynamicLinker=$(cat $CC/nix-support/dynamic-linker) substitute ${./0001-dynamically-patchelf-binaries.patch} $out  --subst-var patchelf

Running a fresh fails, the core message being: Steps to reproduce the behavior: a rust project (or if you already have one) Either the rustup gcc/ld to be patched for NixOS use, or rust to use the system gcc/ld. Please run and paste the result.
Actually, it looks like this is an issue specifically appearing with ; so I'll try to pass the message upstream.
Very specifically, introducing the issue, when it has been decided to switch from the system linker to . I suppose the new binaries should also be elf-patched?
Patching those binaries will make them execute, but they also need the applied so that the binaries they build will also get patched automatically.


Question: <ins> diff --git a/pack.ts b/pack.ts index aba98cc..03ce86a 100644 --- a/pack.ts +++ b/pack.ts @@ -75,33 +75,7 @@ const packageApp = async () => { delete pJson.scripts.prepack; // We don't want to rebuild - all built code will be in the packed content await fs.writeJson(path.join(OUTPUT_DIR, 'package.json'), pJson); -    const buildScript = path.join(OUTPUT_DIR, 'build-release.sh'); - -    // Run build-release in this folder, for each platform. For each bundle, we copy in -    // only the relevant platform-specific NSS files. -    console.log('Building for Linux'); -    await fs.mkdir(path.join(OUTPUT_DIR, 'nss')); -    await fs.copy(path.join(__dirname, 'nss', 'linux'), path.join(OUTPUT_DIR, 'nss', 'linux')); -    await spawn(buildScript, ['linux'], { cwd: OUTPUT_DIR, stdio: 'inherit' }); - -    console.log('Building for Darwin'); -    await fs.remove(path.join(OUTPUT_DIR, 'nss', 'linux')); -    await fs.copy(path.join(__dirname, 'nss', 'darwin'), path.join(OUTPUT_DIR, 'nss', 'darwin')); -    await spawn(buildScript, ['darwin'], { cwd: OUTPUT_DIR, stdio: 'inherit' }); - -    console.log('Building for Win32'); -    await fs.remove(path.join(OUTPUT_DIR, 'nss', 'darwin')); -    await fs.copy(path.join(__dirname, 'nss', 'win32'), path.join(OUTPUT_DIR, 'nss', 'win32')); -    await spawn(buildScript, ['win32'], { cwd: OUTPUT_DIR, stdio: 'inherit' }); - -    // Oclif builds a nodeless platform-agnostic bundle too (although in our case, nothing is -    // really platform agnostic). Not necessary, probably won't work - drop it. -    await fs.remove(path.join( -        OUTPUT_DIR, -        'dist', -        `v${pJson.version}`, -        `httptoolkit-server-v${pJson.version}.tar.gz` -    )); +    await spawn('npm', ['exec', '--', 'oclif-dev', 'pack', '--targets=linux-x64'], { cwd: OUTPUT_DIR, stdio: 'inherit' }); } packageApp().catch(e => { </ins>

HTTP Toolkit is an open-source tool for debugging, testing and building with HTTP(S) on Windows, Linux & Mac. Metadata homepage URL: source URL: license: AGPL v3.0 platforms: linux, darwin
Sorry, wasn't able to get it working. The httptoolkit-server is the difficult part. I tried building from source, however one of the dependencies tries to npm install more stuff in prebuild, so it wasn't building properly. I tried packaging the prebuilt binary but it's trying to do some auto updating and also package node with itself. I could have patched this when building from source, however the prebuilt one is minified & obfuscated so I couldn't do that.
Have you a branch to continue the work ?
+1
I've started a small bounty of 20$ on this: It's not much but it would be great to have this tool on nix!
I made another attempt at packaging this and I'm pretty close to getting httptoolkit-server to compile from source. This should help with patching out stuff, since we can do it before it gets obfuscated.
if anyone needs to run this on nix the appimage provided by HttpToolkit works pretty well on nix with no extra dependencies. See and then Would still be great to have this as a nix package though.
Hey thanks for adding this! You can claim the gitpay bounty here: (I've tried to find your email to invite you but didn't have much luck) or email me at
Sent you an email,


Question: buildInputs = [ makeWrapper ]; postBuild = '' wrapProgram $out/bin/idris  <del> --run 'export IDRIS_CC=''${IDRIS_CC:-${lib.getBin gcc}/bin/gcc}'  --suffix LIBRARY_PATH : ${lib.makeLibraryPath [ gmp ]} </del> <ins> --run 'export IDRIS_CC=''${IDRIS_CC:-${stdenv.cc}/bin/cc}'  --set NIX_CC_WRAPPER_${stdenv.cc.infixSalt}_TARGET_HOST 1  --prefix NIX_CFLAGS_COMPILE " " "-I${lib.getDev gmp}/include"  --prefix NIX_CFLAGS_LINK " " "-L${lib.getLib gmp}/lib" </ins> ''; }

Trying to compile fails with Install (not ) Create with run observe error
has gmp but doesn't have Base or Prelude (which is needed for stuff as simple as )
For reference, I think this issue is related:
You are meant to use to install additional packages with the compiler. I don't understand why the attribute it broken though from a brief look.
I bisected to the commit that caused this: This was in the idris update from 1.3.0 to 1.3.1 Currently looking into how this can be solved elegantly
In the meantime, is there a workaround for this?
Yes, the PR linked above () fixes this, but I'm not sure what to do with it, because it breaks Darwin in weird ways.


Question: hadoop3 = hadoop_3_3; hadoop = hadoop3; <ins> hashlink = callPackage ../development/interpreters/hashlink { }; </ins> io = callPackage ../development/interpreters/io { }; ivy = callPackage ../development/interpreters/ivy { };

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


Question: --bash <($out/bin/olaris-server completion bash)  --fish <($out/bin/olaris-server completion fish)  --zsh <($out/bin/olaris-server completion zsh) <ins> wrapProgram $out/bin/olaris-server --prefix PATH : ${lib.makeBinPath [ffmpeg]} </ins> ''; meta = with lib; {

Olaris server requires ffmpeg to be available and raises an error when it can't be found: Steps to reproduce the behavior: olaris-server a library. The software runs correctly. There are two main ways to fix this: the software to use the full path to the ffmpeg dependency (ideally upstream). the program to add ffmpeg to its path. Please run and paste the result.
In fact it looks like it needs a custom image as it passes arguments that only exist on the modified version.
Actually it looks like the fork is no longer required: But this doesn't seem to be released yet. But probably is still a better option than packaging the custom ffmpeg.
yep, this looks like an easy fix EDIT: I was keen to try building the ffmpeg fork so that we can stick to a released version, however that proved prohibitively difficult, so tip of the default branch it is
no action required, but note the way I used in the pr and commit, means this issue would have autoclosed when the change merged
That is what happened.
sorry, I only saw this issue's update and assumed that you manually closed it; I assume most people involved in nixpkgs prs do not have merge perms, and github really needs to work on their ux. terribly sorry for the hassle, and assuming you were a more novice user.
No worries, GitHub really doesn't make it clear.


Question: else # The state directory is entirely empty which indicates a first start copy_tokens <del> fi        ''; </del> <ins> fi ''; </ins> configureRunner = writeScript "configure" '' if [[ -e "${newConfigTokenPath}" ]]; then echo "Configuring GitHub Actions Runner" args=( --unattended --disableupdate <del> --work "$RUNTIME_DIRECTORY" </del> <ins> --work "$WORK_DIRECTORY" </ins> --url ${escapeShellArg cfg.url} --labels ${escapeShellArg (concatStringsSep "," cfg.extraLabels)} --name ${escapeShellArg cfg.name}

Working with large repositories on low-memory systems (such as aarch64-linux SBCs) can lead to out-of-storage scenarios with the github-runner service because the working directory is set to by default , which is sized to 25% of the system memory by default . Ideally there can be an option to use storage instead of memory for the working directory. I'm opening an issue first because I am not sure if there is a way to work around this already; can the argument in the service be overridden, or is there another way to change for this service with a systemd setting? If there isn't a straightforward solution I can open a PR to add this as an option. Maintainers:
I also experienced issues with no space left on . So far, however, increasing its size did the job. Nevertheless, I'd also appreciate the option to use another filesystem for the runtime directory. We won't be able to use systemd for that as it demands a -like filesystem for the runtime directory.
I guess standard installs avoid this by using the directory. Maybe we should just document how increase size instead of adding another option?
You may pass an arbitrary path to the options of the configuration script. Our module currently always uses the runtime directory systemd assigns to the service.
Yeah, in our case using the runtime directory that provides makes the most sense for dynamic user, again, with documentation on how to increase the size of the runtime directory. Currently our module doesn't support static users so isn't very useful... though I'm guessing our lack of support for static users is an oversight - see details here:


Question: hash = "sha256-5MP6X33Jfu97o5R1n6Og64Bv4ZMxVM0A8lXeQug+bNA="; }; <del> icons = let sparseCheckout = "/release/images/itch-icons"; in </del> <ins> sparseCheckout = "/release/images/itch-icons"; icons = </ins> fetchFromGitHub { <del> owner = "itchio"; repo = "itch"; rev = "v${version}-canary"; hash = "sha256-0AMyDZ5oI7/pSvudoEqXnMZJtpcKVlUSR6YVm+s4xv0="; sparseCheckout = [ sparseCheckout ]; } + sparseCheckout; </del> <ins> owner = "itchio"; repo = "itch"; rev = "v${version}"; hash = "sha256-jugg+hdP0y0OkFhdQuEI9neWDuNf2p3+DQuwxe09Zck="; sparseCheckout = [ sparseCheckout ]; } + sparseCheckout; in stdenvNoCC.mkDerivation (finalAttrs: { pname = "itch"; inherit version; </ins> <del> nativeBuildInputs = [ copyDesktopItems makeWrapper ]; </del> <ins> src = fetchzip { url = "https://broth.itch.ovh/itch/linux-amd64/${finalAttrs.version}/archive/default#.zip"; stripRoot = false; hash = "sha256-4k6afBgOKGs7rzXAtIBpmuQeeT/Va8/0bZgNYjuJhgI="; }; nativeBuildInputs = [ copyDesktopItems makeWrapper ]; </ins> desktopItems = [ (makeDesktopItem {

Package name: itch Latest released version: 26.1.3 Current version on the unstable channel: 26.1.3 Current version on the stable/release channel: 26.1.3 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- The current version is broken since butler is marked broken 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]:
The latest version on seems to be 26.1.3 which is used in the package.
There is 26.1.5 as a source code , but current package uses binaryBytecode


Question: , enableKernelPoll ? true , javacSupport ? false, javacPackages ? [ openjdk ] , odbcSupport ? false, odbcPackages ? [ unixODBC ] <del> , wxSupport ? true, wxPackages ? [ libGLU_combined wxGTK xorg.libX11 ] </del> <ins> , wxSupport ? !stdenv.isDarwin, wxPackages ? [ libGLU_combined wxGTK xorg.libX11 ] </ins> , preUnpack ? "", postUnpack ? "" , patches ? [], patchPhase ? "", prePatch ? "", postPatch ? "" , configureFlags ? [], configurePhase ? "", preConfigure ? "", postConfigure ? ""

The current wxmac port fails to build. Build wxmac from latest git. wxWidgets uses some deprecated CoreFoundation functions, which are no longer there. Upstream version 3.0.4 still uses these functions. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(sperber): nixpkgs:
That's very annoying! There has been a recent update of CF by that uses CF from Apparently they don't implement these deprecated APIs. We should be able to patch it to fix these references and use updated APIs. For now though you will probably be stuck on 18.03 or 18.09 if you need wxmac.
Yeah, I looked into that for a while, but the references to the now-unsupported FSRef type are pretty widespread in the wxmac codebase. :-( (I don't need wxmac directly, but erlang depends on it.)
Yeah, I patched those calls out of QT 4 but haven't gone and looked for other stuff that uses them.
Looking at source, it doesn't look like those functions are really used in any essential way. If you look at who calls , it doesn't really seem to be used anywhere much, and is used to set some icons. Or vice versa, but either way doesn't seem like it would be hard to patch out.
I was thinking the same thing, but my impression was that these are part of the public API of wxWidgets.
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 . on the on .


Question: rev = version; hash = "sha256-Gc22Y2T4uO39jiOqEUFeOfnVCbknuDjmzFPZgk2eY74="; }; <ins> patches = [ ]; </ins> nativeCheckInputs = old.nativeCheckInputs ++ [ self.tomli-w ];

Steps to reproduce the behavior: Tested on a MacOS 12.6.7 (Monterey) on a MacBook Pro 2016 (x86) Please run and paste the result.
The logs above say 1.6.1, not 1.5.1 - I think the title needs to be edited to reflect the correct version I'm seeing the same error with poetry 1.6.1 on macOS Venture 13.4.1, 2018 MacBook.
Thanks , that's strange, I'm new on nix and I thought the version nix were installing was the one I got using (). Looking on github the official poetry version is 1.5.1 () while poetry-core is 1.6.1 () but it seems that poetry-1.5.1 is failing. If not, can I ask your support to "decode" the logs? :) Thanks
It's poetry-core 1.6.1 that's failing to build. Try building .
Oh, that's right, thank you. I'll update the title and the notes.


Question: inherit (binary) platform checksum; in stdenv.mkDerivation rec { pname = "cypress"; <del> version = "13.2.0"; </del> <ins> version = "13.13.2"; </ins> src = fetchzip { url = "https://cdn.cypress.io/desktop/${version}/${platform}/cypress.zip";

Package name: cypress Latest released version: 13.13.2 <!-- Search your package here: --- Current version on the unstable channel: 13.2.0 Current version on the stable/release channel: 13.2.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! --- The following PR exists but seems to be abandoned: Weirdly enough I am also experiencing that the 13.2.0 version actually delivers 12.17.1, I don't know why...: ! Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: <ins> { lib, buildPythonPackage, fetchPypi, click, colorama, flask, requests, yt-dlp }: buildPythonPackage rec { pname = "yark"; version = "1.2.3"; src = fetchPypi { inherit pname version; sha256 = "sha256-KMnQpEH2Z19Y0jBjqx2rZjmlle2M9bcuDCjDIljQEYY="; }; propagatedBuildInputs = [ click colorama flask requests yt-dlp ]; # There aren't any unit tests. If test discovery runs, it will crash, halting the build. # When upstream adds unit tests, please configure them here. Thanks! ~ C. doCheck = false; meta = with lib; { description = "YouTube archiving made simple"; homepage = "https://github.com/Owez/yark"; license = licenses.mit; }; } </ins>

Project description Yark lets you continuously archive all videos and metadata for YouTube channels. You can also view your archive as a seamless offline website. Not a high priority request, but could be useful. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin (anything with Python 3)


Question: homepage = "https://teamspeak.com/"; sourceProvenance = with sourceTypes; [ binaryNativeCode ]; license = { <ins> # See distribution-permit.txt for a confirmation that nixpkgs is allowed to distribute TeamSpeak. </ins> fullName = "Teamspeak client license"; url = "https://www.teamspeak.com/en/privacy-and-terms/"; free = false; }; <del> maintainers = with maintainers; [ lhvwb lukegb atemu ]; </del> <ins> maintainers = with maintainers; [ lhvwb lukegb atemu ]; </ins> mainProgram = "ts3client"; platforms = [ "x86_64-linux" ]; }; } <del> /* License issues: Date: Mon, 10 Dec 2007 19:55:16 -0500 From: TeamSpeak Sales <sales@tritoncia.com> To: 'Marc Weber' <marco-oweber@gmx.de> Subject: RE: teamspeak on nix? Yes, that would be fine.  As long as you are not renting servers or selling TeamSpeak then you are more than welcome to distribute it. Thank you, TeamSpeak Sales Team ________________________________ e-Mail: sales@tritoncia.com TeamSpeak: http://www.TeamSpeak.com Account Login: https://sales.TritonCIA.com/users -----Original Message----- From: Marc Weber [mailto:marco-oweber@gmx.de] Sent: Monday, December 10, 2007 5:03 PM To: sales@tritoncia.com Subject: teamspeak on nix? Hello, nix is very young software distribution system (http://nix.cs.uu.nl/) I'd like to ask wether you permit us to add teamspeak (server/ client?) Sincerly Marc Weber (small nix contributor) */ </del>

Steps to reproduce the behavior: try to install/build the package using nix-shell or nixos the Domain is no longer configured. Teamspeak Download Pages redirects to this place: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
You might want to check out
Not merged yet
As a workaround, until this is fixed in nixpkgs: The file is still available at the Internet Archive. You can fetch it from there and write it into the store, with something like this:


Question: ;;; from: /nix/store/<hash>-emacs-<version>/share/emacs/site-lisp/site-start.el ;;; to:   /nix/store/<hash>-emacs-<version>/share/emacs/<version>/src/ (let ((emacs <del> (file-name-directory                      ;; .../emacs/ (directory-file-name                     ;; .../emacs/site-lisp (file-name-directory load-file-name)))) ;; .../emacs/site-lisp/ </del> <ins> (file-name-directory                      ; .../emacs/ (directory-file-name                     ; .../emacs/site-lisp (file-name-directory load-file-name)))) ; .../emacs/site-lisp/ </ins> (version (file-name-as-directory (concat

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: buildPythonPackage rec { pname = "rapidfuzz"; <del> version = "2.13.2"; </del> <ins> version = "2.13.3"; </ins> disabled = pythonOlder "3.7";

Steps to reproduce the behavior: python3Packages.rapidfuzz Introduced in . Please run and paste the result.
It appears that cmake selects an incorrect linker. I am currently unsure what's the reason for this. Following I think I might need to set: I have zero experience with nix os + no access to a mac. Is there any way to patch in the build system here to check whether this solves the issue?


Question: "-DCMAKE_BUILD_TYPE=RelWithDebInfo" ]; <ins> postInstall = '' for i in $out/bin/*; do wrapProgram $i --prefix PYTHONPATH : "$PYTHONPATH" done ''; </ins> meta = with lib; { description = "A free and open source painting application"; homepage = https://krita.org/;

the python binding for krita are not build correctly. Please run and paste the results.
more details wouldn't hurt...
well I don't exactly know what is happening here, to build the python binding, it requires and . So when are to the buildInputs, cmake finds all the dependencies correctly; however, at around 98% the compilation fails due to not finding some sip bindings. Alternatively, if is to the buildInputs, everything works fine as intended. But the python interpreter overwrite the python interpreter in the nix-env, so that doesn't seem to be the right fix.
also tried setting the variable, but that didn't work either.
cc who worked on / in


Question: outline = handleTest ./outline.nix {}; image-contents = handleTest ./image-contents.nix {}; openvscode-server = handleTest ./openvscode-server.nix {}; <ins> open-webui = runTest ./open-webui.nix; </ins> orangefs = handleTest ./orangefs.nix {}; os-prober = handleTestOn ["x86_64-linux"] ./os-prober.nix {}; osquery = handleTestOn ["x86_64-linux"] ./osquery.nix {};

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


Question: , ghc_filesystem , msaClientID ? "" , jdks ? [ jdk17 jdk8 ] <ins> , gamemodeSupport ? true , gamemode </ins> }: let

A clear and concise description of what the bug is. Prism Launcher doesn't allow enabling Feral GameMode or MangoHud under the "Performance" tab because it can't find it. Steps to reproduce the behavior: GameMode ( ) MangoHud ( ) Prism Launcher ( ) new instance in Prism Launcher instance and go to "Performance" tab A clear and concise description of what you expected to happen. GameMode and MangoHud should be able to be enabled when installed. If applicable, add screenshots to help explain your problem. ! ! Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
Addressed here -


Question: enableParallelBuilding = true; <ins> # separateDebugInfo breaks static build # https://github.com/NixOS/nixpkgs/issues/219466 separateDebugInfo = !stdenv.hostPlatform.isStatic; </ins> doCheck = true; # Some of the tests use localhost networking.

Neovim frequently coredump It is hard to reproduce the behavior, it always breaks down in unexpected situations no core dump ! <!-- 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.
It might be caused by neo-tree. I haven't seen any crashes since I moved from neo-tree to nvimtree.
Also pretty sure it's neo-tree, I have the same issue . I've already built debug symbols for and am waiting for the next crash to get a detailed report.
not nixpkgs relevant (report to neovim with stacktrace).


Question: buildGoModule rec { pname = "auth0-cli"; <del> version = "1.5.0"; </del> <ins> version = "1.4.0"; </ins> src = fetchFromGitHub { owner = "auth0"; repo = "auth0-cli"; rev = "refs/tags/v${version}"; <del> hash = "sha256-C4zKWMrWGrnamlcugrOUUUdCUwYDgiD6XKdBQ3bBWFI="; </del> <ins> hash = "sha256-j7HT57/4rrrVkx9Zz+XuWD6UL0spdej+U5gWtFo1FSI="; </ins> }; <del> vendorHash = "sha256-VeH7EDMNrdJSWHioz2O29NiGtC59IdWYww3WoABO4LY="; </del> <ins> vendorHash = "sha256-bWAneCRsQbPRxEM/3jr1/Lov6NV67MRycOgrlj3bKF8="; </ins> ldflags = [ "-s"

Steps to reproduce the behavior: auth0-cli from the unstable Failing to fetch sources following The 1.5.0 release from Auth0-cli has disapeared from GitHub Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: scala_2_11 = callPackage ../development/compilers/scala/2.x.nix { majorVersion = "2.11"; jre = jdk8; }; scala_2_12 = callPackage ../development/compilers/scala/2.x.nix { majorVersion = "2.12"; }; scala_2_13 = callPackage ../development/compilers/scala/2.x.nix { majorVersion = "2.13"; }; <ins> scala_3 = callPackage ../development/compilers/scala { }; # deprecated dotty = scala_3; </ins> scala = scala_2_13; scala-runners = callPackage ../development/compilers/scala-runners {

Project description Scala 3 is more than a year old. It would be nice to have it packaged in nixpkgs as well. Maybe it is, but I couldn't find it under "scala-3" or respective versions. Metadata homepage URL: https://scala- source URL: license: Apache-2.0 License platforms: unix, linux, darwin, ...
is already packaged.
Indeed: the Scala 3 compiler started out under the codename 'dotty', and that's how it was packaged initially in nixpkgs. Now that dotty has become the 'official' scala 3 compiler (see also ), we should probably rename the package to as well? /cc
Feel free to update, rename and alias the old name :) Maybe should point at and can be