This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there → /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h → /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h → propagatedBuildInputs → propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.


Steps to reproduce the behavior: sure that the system is set up for cross-compiling (extra-platforms). The following patch fixes the cross-build I am looking for (but it might break other builds, I don't know): Issue seems to be that the configure script of libvpx does not know the target (as a result, we need to force it), which results in a mess. By using instead of , the target is understood and everything works for me. Please run and paste the result.
I'm experiencing this issue as well, I'll test your patch in ExpidusOS and I'll reply back with whether or not it works.
After applying your patch, I wasn't able to build it. I'm going to look into what wants it to be so it could compile.
I was able to successfully cross compile , I'll work on bundling into a PR later.
still an issue, and it seems like the fix for armv7l really is as simple as described in this bug report (i.e. change the target flag from "armv7l-linux-gcc" to "armv7-linux-gcc"). if you get a chance to upstream that patch, i'd be happy to test it for cross aarch64-multiplatform and armv7l-hf-multiplatform.
Done. Fixed by .


Steps to reproduce the behavior: , set the following: Then navigate to a git repo (e.g. nixpkgs) and call Git logs and a success message Nushell prints the following error: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I have proposed a fix in


This issue was described by kvtb at Quoting: Extende the ExecStartPre with something like: Currently the unit depends on , maybe there is something smarter to do.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
might be more suitable?


I'm trying to install ncdu on darwin, which depends on zig; it has started failing to build in recent nixpkgs on the 22.11 track, though. Steps to reproduce the behavior: zig installs cleanly. <details<summaryoutput of nix log</summary<p</p</details Please run and paste the result.


NixOS 16.09:
Merged to 16.09 in , hope it works for you. I haven't exactly tested this extensively. It builds and the test programs it produces pop up windows :-)
Thanks! For my edification, would you mind pointing out how you knew that needed to change to ? I was trying to PR this myself but never figured that out.
Well, I first tried just updating the version, but as you also noticed it wouldn't build. In the build output it wrote however, and this certainly makes multiple-outputs a prime suspect. So I did and modified to also have with the include path in the output. Note the one is still there. After that I wasted some time trying to get Tk to use the system libjpeg but gave up on that after a while :-)


The icu541 package fails to compile at the patching step. Some of the patches issue warnings, others fail completely. Install icu541: . The build process will fail. System: NixOS: 16.09 Nix version: 1.11.4 Nixpkgs version: 16.09.1202.


Once in several days, my X session crashes. It always happens at the time systemd-tmpfiles- runs. Here is the corresponding part of [ .525] (WW) Open ACPI failed () (Connection refused) [ .994] (II) config/udev: removing device Power Button [ .006] (II) evdev: Power Button: Close [ .006] (II) UnloadModule: "evdev" [ .006] (II) config/udev: Adding input device Power Button (/dev/input/event4) [ .006] () Power Button: Applying InputClass "evdev keyboard catchall" [ .006] () Power Button: Applying InputClass "Keyboard catchall" [ .006] (II) Using input driver 'evdev' for 'Power Button' [ .006] () Power Button: always reports core events [ .006] () evdev: Power Button: Device: "/dev/input/event4" [ .006] (--) evdev: Power Button: Vendor 0 Product 0x1 [ .006] (--) evdev: Power Button: Found keys [ .006] (II) evdev: Power Button: Configuring as keyboard [ .006] () Option "configinfo" "udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input11/event4" [ .006] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 6) [ .006] () Option "xkbrules" "evdev" [ .006] () Option "xkbmodel" "pc104" [ .006] () Option "xkblayout" "us" [ .006] () Option "xkbvariant" "intl" [ .006] () Option "xkboptions" "ctrl:nocaps" [ .770] (II) Open ACPI successful () [ .770] (II) config/udev: removing device Video Bus [ .775] (II) evdev: Video Bus: Close [ .775] (II) UnloadModule: "evdev" [ .775] (II) config/udev: Adding input device Video Bus (/dev/input/event15) [ .775] () Video Bus: Applying InputClass "evdev keyboard catchall" [ .775] () Video Bus: Applying InputClass "Keyboard catchall" [ .775] (II) Using input driver 'evdev' for 'Video Bus' [ .775] () Video Bus: always reports core events [ .775] () evdev: Video Bus: Device: "/dev/input/event15" [ .775] (--) evdev: Video Bus: Vendor 0 Product 0x6 [ .775] (--) evdev: Video Bus: Found keys [ .775] (II) evdev: Video Bus: Configuring as keyboard [ .775] () Option "configinfo" "udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/input/input23/event15" [ .775] (II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD, id 8) [ .775] () Option "xkbrules" "evdev" [ .775] () Option "xkbmodel" "pc104" [ .775] () Option "xkblayout" "us" [ .775] () Option "xkbvariant" "intl" [ .775] () Option "xkboptions" "ctrl:nocaps" [ .839] (II) config/udev: removing GPU device /sys/devices/pci0000:00/0000:00:02.0/drm/card0 /dev/dri/card0 [ .839] xf86: remove device 1 /sys/devices/pci0000:00/0000:00:02.0/drm/card0 [ .839] failed to find screen to remove [ .935] (II) config/udev: removing device Video Bus [ .941] (II) evdev: Video Bus: Close [ .941] (II) UnloadModule: "evdev" [ .941] (II) config/udev: Adding input device Video Bus (/dev/input/event14) [ .941] () Video Bus: Applying InputClass "evdev keyboard catchall" [ .941] () Video Bus: Applying InputClass "Keyboard catchall" [ .941] (II) Using input driver 'evdev' for 'Video Bus' [ .941] () Video Bus: always reports core events [ .941] () evdev: Video Bus: Device: "/dev/input/event14" [ .941] (--) evdev: Video Bus: Vendor 0 Product 0x6 [ .941] (--) evdev: Video Bus: Found keys [ .941] (II) evdev: Video Bus: Configuring as keyboard [ .941] () Option "configinfo" "udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input22/event14" [ .941] (II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD, id 7) [ .941] () Option "xkbrules" "evdev" [ .941] () Option "xkbmodel" "pc104" [ .941] () Option "xkblayout" "us" [ .941] () Option "xkbvariant" "intl" [ .941] () Option "xkboptions" "ctrl:nocaps" [ .942] (II) config/udev: Adding input device Lid Switch (/dev/input/event2) [ .942] (II) No input driver specified, ignoring this device. [ .942] (II) This device may have been with another device file. [ .942] (II) config/udev: removing GPU device /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1 /dev/dri/card1 [ .942] xf86: remove device 0 /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card1 [ .963] (EE) [ .963] (EE) Backtrace: [ .972] (EE) 0: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (OsSigHandler+0x29) [0x5954c9] [ .972] (EE) 1: /nix/store/jm1n87rp8vr90j9ahcrfzr57nc2r8vgf-glibc- (restorert+0x0) [0x7f27cfc91e8f] [ .990] (EE) 2: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server- (FreeScreen+0x23) [0x7f27c4df9413] [ .993] (EE) 3: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (xf86DeleteScreen+0x5a) [0x481d4a] [ .993] (EE) 4: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (xf86platformRemoveDevice+0x11e) [0x49612e] [ .994] (EE) 5: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (DeleteGPUDeviceRequest+0x9b) [0x49bb4b] [ .994] (EE) 6: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (deviceremoved+0xdf) [0x49785f] [ .994] (EE) 7: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (wakeuphandler+0x90) [0x498460] [ .994] (EE) 8: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (WakeupHandler+0x5c) [0x43c07c] [ .994] (EE) 9: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (WaitForSomething+0x1f6) [0x58dd86] [ .994] (EE) 10: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (Dispatch+0x8e) [0x43734e] [ .994] (EE) 11: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (dixmain+0x3c3) [0x43b543] [ .995] (EE) 12: /nix/store/jm1n87rp8vr90j9ahcrfzr57nc2r8vgf-glibc- (libcstartmain+0xf0) [0x7f27cf0a92e0] [ .995] (EE) 13: /nix/store/0195lcgvy4g6vihbfm4qqfa9cckkpcfa-xorg-server-1.18.3/bin/X (start+0x2a) [0x4258ba] [ .014] (EE) 14: ? (?+0x2a) [0x2a] [ .014] (EE) [ .014] (EE) Segmentation fault at address 0x8 [ .014] (EE) Fatal server error: [ .014] (EE) Caught signal 11 (Segmentation fault). Server aborting [ .014] (EE) [ .014] (EE) Please consult the The X.Org Foundation support at for help. [ .014] (EE) Please also check the log file at "" for additional information. [ .014] (EE) I can't reproduce the crash, it happens randomly. System: 16.09.1229. (Flounder) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "16.09.1229."
I wonder if we'd better pick Xserver bump to 16.09: .
Hmm, I picked it, whether it fixes this problem you experience or not. I expect it to hit the channel within a couple days.
These lines seem suspicious: .
I have a computer in my living room with nixOS 16.09 on it. Since about a month every time I close the screen (the TV), the X server close itself. It does not segfault. But I have the same suspicious line in X11's logs. Any idea what cause the bit? Obviously, in my case, the "shotdowning" of the screen triggers that, but why? It might be related to what have.
Maybe its X11 trying to reconfigure itself. Maybe providing a configuration file would prevent it.
On one Intel-based desktop I was occasionally getting into an irrecoverable black-screen state on some similar conditions (all but the screen seemed OK), but I don't have any logs of that anymore.
Sorry for the spam, but I forgot to say that I didn't have this problem when I first installed nixOS 16.09 on this computer (fresh install), I installed it right before the official release of 16.09. The problem started to occurred after an upgrade, but I can't tell exactly when.
My computer too uses Intel graphic.
Maybe a different kernel? Does this occur on all the kernel versions currently available in release-16.09?
I've got 4.4.x all the time on that machine.
(triage) does this still happen?
I don't know, I don't use nixOS anymore.
I am closing then. If anyone experiences this issue, I will be glad to reopen.


Project description From the : Metadata homepage URL: source URL: license: MIT platforms: linux


Seems to be related to PR Steps to reproduce the behavior: from master branch () the result share directory () the state of the man link () This will result into build error if used on nixos system with enabled man pages last line of trying to rebuild the system Either working link to man page or at non at all.


First failure in Likely due to
The referenced file is indeed missing from source: Our fetcher should include submodules.
Changed in , where is converted into a submodule.
These qt modules currently include submodules:


Steps to reproduce the behavior: i noticed the break after the nheko 0.10.2 -0.11.0 upgrade landed in nixos-unstable: hydra failure (click for the build log): build is currently broken in both master () and has been fixed in nixos-22.11, see for having initiated the backport. tagging as maintainer of both mtxclient and nheko. Please run and paste the result.
tested against the outstanding mtxclient 0.9.0 -0.9.1 PR: still broken.
I have no idea why a standard library would depend, let alone be missing, on a different architecture.
Likely due to us using outdated gcc (gcc9) on aarch64-linux. The story is complicated, but is being addressed.
Forcing it to use gcc11Stdenv may fix the issue.
It seems so: I tested by cross-compiling mtxclient (I don't have an aarch64 system).
Opened
Great... now coeurl fails to build. EDIT: Fixed, but nheko is still broken.
hope nobody minds this extra notification that is me thanking you all for jumping in so readily to fix things, even for someone you’ve never met. anyone reading this: what you’re doing here has more impact than you know.


After enabling with (CLI and GUI) I am unable to use any other protocol except wireguard Steps to reproduce the behavior: and related service from channel , switch to openvpn, try connecting All protocols should work Clearly lacks some files: Probably needs something similar to whatever is done in (CLI) package:
works as expected, but is broken. We can wrap MULLVADRESOURCEDIR for in like in . I''ll make a quick fix. Maybe I don't understand something, but why do we have two mullvad packages? cli and gui are both from the same repository, maybe we can merge this two packages and make some aliases for those, who wants to install cli and gui separately?


Steps to reproduce the behavior: libreoffice-fresh off master 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.
Is this issue closed because it is solved? It's still happening to me: If I include in my config, fails with the message . If I exclude from my config, rebuilding succeeds. I'm using the channel.
Yes, it's just that the commit hasn't arrived yet at nixos-unstable, see .


Recently, we fixed : However, on , still fails to run on my machine throughing the dreaded: Steps to reproduce the behavior: run nixpkgs#puddletag The application seems to be correctly wrapped: but still, it does not work. and myself. Please run and paste the result.
There’s definitely an impurity somewhere - it’s working perfectly fine here. I hadn’t used it in a while, but it runs with nixos-unstable` currently on this machine.
This is interesting. The command definitely fails for me. (I was incorrectly saying , but I am also using ). I have trouble debugging this. I had a look at the wrapper shell script, and all looks fine. The paths are ok and do exist.
That seems to indicate an impurity then.
This is also happening on nixos-22.11, not just unstable. A friend is having this issue, so I tested it out for myself and got the same thing. For what it's worth, we both use i3, so the impurity may be related to things a DE would normally set up.
runs fine for me.
So definitely a purity thing then. Care to do a PR?
Sure, I suppose. Just a minute.
Hi! Thanks for looking into this! I could not test the PR directly because the review process starts to build Python Pandas an whatnot. However, I could start using the fix of Some remarks: The wrapper without the fix is: The file with the fix (adding the Qt wrapper line): So there is a substantial difference, and wrapping doesn't seem to work properly without the extra line, even though it should work. Further, when opening on using the fix, the program crashes when clicking with the following error: I do not think this is related to the wrapping, but it should definitely also be fixed. Somehow, is not found.
My version wraps twice, so the original wrapper and all its settings are still there, in , while the real puddletag script is now in . There's a note at the bottom of which says that doesn't wrap scripts, only ELF binaries. I don't know what the reasoning for that is, but apparently invoking the wrapping manually is "what you're supposed to do". At least as far as I could tell.
Ok I see. So the first wrapper handles the python dependencies, and the second one the qt dependencies. Is that so?
Counting the layers outward from the core (rather than, say, in execution order), yes, that's correct.
Then we should modify the wrapper args instead to avoid double-wrapping.
Well, to do that, I believe you'd need to reimplement either the python wrapping or the qt wrapping systems, which seems prone to breakage.


Project description RiscPC Emulator Metadata homepage URL: source URL: license: gpl2 platforms: linux, darwin This also includes ROM images which could also be downloaded, as ROOL maintains these on an open source licence. Not sure the best idea for these... /var/lib? Thanks very much for all your hard work.
Builds and compiles. I will upload it tomorrow
The roms are mostly optional, in the sense the software will seek them in . There is no such a need for include them now.
Thanks very much.
how did you get it to work? I can't get it to recognize the existence of the hostfs folder.


Project description spotify-player is a fast, easy to use, and configurable terminal music player. Metadata homepage URL: source URL: license: MIT platforms: linux, windows, darwin


On or cross-compiled from , breaks: From : You can either run this on another architecture using . or should not crash: This was responsible for failing to replicate datasets to my ARM NAS. The issue does not_ occur for natively compiled builds. It appears to be a cross-compilation issue only.
It is a bug in / derivations. In non-cross cases it gets copied from used to bid into output: But in cross-case used to build does not yet provide as it needs bits of for it (and the library path is slightly incorrect). One of possible workarounds is to try to add to to get it pulled via from expected location.
We don't do the copying to glibc anymore, but this error still occurs as described on current nixpkgs master.
Yup. cross-compilation never propagated to in any form (and does not today).
Could you please try this PR? It should fix the problem.
With that PR, I'm seeing this on both (a Raspberry Pi CM4) and with QEMU on : Log from aarch64 machine: Log from machine with QEMU:
Well it's finding now, so there's clearly some other problem with addition to that. When I run it with I even get line numbers from inside : That line () is the last line in the following snippet of code: ... so is deliberately ing here due to . Grepping through the docs turns up: This is happening because uses . Once you do that, glibc needs to unwind the stack frame of any thread that calls . And unwinders are a giant headache. I'm afraid that's all I've got here. I've removed the closed-by from since it was only part of the problem here.
Ah, I think I know what it is. We can compile a without , but it won't have an unwinder. We need to pass the glibc headers to the build in order to get one of those.
would you please try ? I believe it fixes one of the two problems which caused this issue, and it includes which fixes the other one. It works for me: BTW, this issue (cross-compile , then run it under qemu) is a really valuable test case. We really ought to add it to so Hydra will catch any regressions automatically. Especially since the failure mode gives the user no error message to help them troubleshoot the problem! is a great candidate for this since it's one of those very rare non-C++ programs that uses advanced stack-unwinding features from pthreads.
Confirming fixes the issue. Tested with both and on real hardware and with QEMU on x86_64.
~I think this is fixed, and more cleanly,~ by Edit: it is not. :frowning_face: I will keep trying. Test is in Currently building.
Added this to , but commented out since it is not fixed yet.


<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: msmtp <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.8.22 desired version: 1.8.23 <!-- 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.


build Full logs: Errors happen when building for musl, dynamic. Alpine package: Nixpkgs package:
This can be fixed by a , but I'm not sure if we want this?


I want to change a configuration variable to onlyoffice. Currently, the NixOS module adapts on the fly in the upstream configuration with a call. I'd like to make my own adaptation. For now it's not possible due to ExecStartPre being not declared as a list, but as a direct value.


SpamAssassin generates and compiles C code from anti-spam rules. This currently fails because the generated code makes use of the function, which is not available during the rule compilation process. Steps to reproduce the behavior: the SpamAssassin service that sa-update.service fails with the error message: that, consequently, spamd.service will not function. Alternatively, the error can also be observed by invoking directly. sa-update.service succeeds <!-- 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.
A smoke-test that serves as a reproducer is available in .
In theory, this could be addressed by making libxcrypt available when compiling rules, but care must probably also be taken so that the dynamic linker can find it at rule run-time.
Rule compilation seems to complete without errors for the rule if we set . However, of course the resulting binary is not linked against libxcrypt then. I’m not sure when Spamassassin will generate code that actually calls functions from that library.


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


According to documentation of the app: there's a dozen dependencies we don't explicitly have a dependency on, so there's multitude of bugs that might appear depending on what's on $PATH.
Do we need a new maintainer of to move this issue forward?
We should pull the package from NixOS core...absolutely no reason to have such a bloated less ship by default.


LibreSSL 3.4 is no longer supported upstream. It became unsupported on October 14th 2022, one year after . At the time of writing, 3.5 and 3.6 are both supported. that fixes a serious vulnerability: I suspect (but haven’t verified) that this vulnerability is present in LibreSSL 3.4. It is time to remove it from Nixpkgs. However, there are some packages that still depend on it. all depend on . I tried building against and , but both fail. I don’t see any packages that depend on , so I think we could remove the older versions, if we can first update FoundationDB to a version that is compatible with a more recent LibreSSL release. Maybe will be sufficient for this. Alternatively, we might patch FoundationDB. The compilation errors are about an incomplete type for which only a forward declaration is known. I haven’t looked into it deeply but it may be easy to fix. as the maintainers of , what are your thoughts on this? This has been addressed by . <details<summaryOriginal comment</summaryThe other package that explicitly depends on LibreSSL 3.4 is . This is a proprietary package so I couldn’t test if it is compatible with a more recent LibreSSL release, it might actually be. as the maintainers of , could you try and see if it is compatible with a newer LibreSSL release? </details
The x400Address issue that was patched recently is present in LibreSSL 3.4. The fix is very small and applies to all older versions that have it, so it might be an option [patch it][1] while you sort out the other issues. If you could share build logs for the foundationdb issues I can take a look if you want. [1]:
You can drop this. uses their bundled OpenSSL and drops the dependency since it's incompatible with even this LibreSSL version. It's about to merge.
all of darwin depends on 34 at the moment. You've pinned to 3.4, do you know if by any chance we can upgrade to 3.5 ? maybe ?
I'm quite sure we can't. My history with that package is and . happened, because someone did . iirc happened, because this package depends on ancient long unsupported openssl APIs that weren't part of anymore.
Small rectification, after a bit more testing, it doesn't appear to be all of darwin that is impacted by that change. So perhaps we don't need to put too much effort into this. I'm still trying to figure out the impact.
I’m working on a fix for , which drops the dependency on from by unconditionally dropping Unbound from the build (instead of only on aarch64-darwin). Apple doesn’t even include Unbound in macOS anymore, and it’s not present in newer source releases. That should remove as a blocker for dropping LibreSSL 3.4.


I wanted to setup unbound on a server. I did have this configuration: I then manually created the file using in the folder as it did not automagically create one. The folder was set to 0777 permissions and the key to 0666. I checked then the systemd status: All looked fine. Port 5335 also opened on the firewall. Basically running PiHole container there that should call unbound for recursive resolution. As systemd showed unbound running, I tried to do a query but it errored out: Interestingly I run unbound on another server. On the other server I did not set the as it does not wipe everything that's not explicitely saved (see ). I thought I would need the on this setup, as everything gets wiped on reboot that is not explicitely set to save. After removing the option from the configuration, unbound works as expected. So there are two problem with the option: does not get automagically created don't work system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:


p7zip source is gone try to build without substituters cc
What commit are you having the issue from? it works for me at
Current master, that is sets to . There is no such tag at
Maybe the fork cleared the tags by force pushing?
Hmm, I wonder if all the changes got merged into with the fork then rebasing and force-pushing…
Yeah, looks like it. A bunch of jinfeihan57's commits are now in the commit history I'll change it to point back to p7zip-project's copy now


Project description CryptPad is a collaborative office suite that is end-to-end encrypted and open-source. Enable this a service for NixOS. Metadata homepage URL: source URL: license: agpl2 platforms: unix, linux, darwin, ...
CryptPad used to be included in nixpkgs, but it was removed because there weren't enough maintainers. The removal occurred with the commits and .
Not quite true: it was removed because they had a strong dependency on out-of-date software. . Now, there is an ongoing effort to re-introduce it in : .


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


Steps to reproduce the behavior: -env -i gotop Happy to provide more info if needed. <!-- 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.
Maybe we can apply as a patch.
can you try latest master ? gotop 4.2.0 should aleady contain patch mentioned by


Linux app for streaming music from YouTube. <!-- Monophony is a free and open source Linux app for streaming music from YouTube. It has no ads and does not require an account. --Metadata homepage URL: source URL: license: mit platforms: linux
I'd be interested in doing this if its not too hard, I'll look into it.
The package is almost done, had some complications including unpackaged dependencies, but it should be good to go within the next few days.
Just waiting for a merge now.


I'm trying to do something similar to the following: Apparently, however, does not translate the Nix list into a Bash array as I'd expect. I see the following error: Add to the attributes which contains a argument with whitespace. For example: This results in a bash array with the following items (one per line): Use the following patch to print the array members: Please run and paste the result.
Using flags with spaces as a derivation attribute can . I'd append to in , as explained in the link:
Thanks for your comment. That's frustrating. I wonder if should have an argument at all, if it works sometimes. Also, I think manipulating in does not work as the defined by run first.
Spaces can be supported if some quoting is to : This is also how it's done in Python's build-support:


While rebuilding on this system that requires the package a failure while building has been occurring since NixOS 22.11. One of the tests fails.
I am not the maintainer of this package. Maybe can help? also have a look at:
Silly me for not checking and just the current release, disabling tests is a hell of a workaround but definitely works!
I'm also not a maintainer of the package, but I'm happy to fix it nonetheless :) There's an issue in that we don't have a good way of setting HDF5PLUGINPATH appropriately. Maybe I'll come back and fix this at some point, but for now this will do...


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).


grub fails with nixos-rebuild switch -I nixpkgs=/home/lethal/nixpkgs
The issue title here is highly uninformative, which is why I didn't find this when checking for duplicates. :P


When running , sometimes fails to start with an error message: Run System: NixOS: Nix version: Nixpkgs version:
I can confirm this issue. It also delays restarting of other units (probably dependent services) after upgrade. I do: as a workaround when this happens, so that the other services can restart faster. It only happens on my physical machine. My v-server never had this problem.
Can confirm this is still happens on 17.09 (just happened right now, and has been happening on every single ).
My workaround is to use:
how do you specify that? I get:
there was a typo: UPDATE 2: One also need to make it a list to override!
The solution posted above no longer seems to work after upgrading to 18.09 - has anyone else solved this in a different way?
Ran into this issue when I didn't have the EFI boot partition mounted while rebuilding. I think I was starting up an old nixos configuration. Seems to work fine now.
I forgot to make it a list. The empty string makes systemd first resets the option so it can be overriden afterwards.
A potential fix is also here: I want to test this option a bit for myself first.


See also Steps to reproduce the behavior: This is such as basic cross-compilation that I wonder whether something is wrong in my setup. However, the errors are surprising, because I thought most packages were cross-compilation aware enough to not run host binaries on the build platform. Please run and paste the result.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
was mentioned as a possible fix.
I can confirm that fixes this issue.


From a brief look at the updated cuda section in the manual, it would be logical to take as an argument, rather than the compiled string. And to expose that in via gets even further beyond the scope, so let's skip it Originally posted by in
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


The program Jabref will build, but give a JFX related error upon trying to run the program. Steps to reproduce the behavior: The program launches as it used to. Please run and paste the result.
It's fixed in but hasn't been merged.
Hi. Sorry for digging this up, but I'm having the same error for starting a JFX application inside Intellij IDEA, where is unable to find (or ). My hack to resolve this involves: Make sure that there is within your ( for example) Add the path to :Start Intellij IDEA from the shell. I felt like this is worth a separate issue (Intellij and JFX related), but wanted to ask it here first. Many thanks!
I can't understand what you want to ask... This issue is caused by the reason said in
I meant I had the same issue (missing for ), but in another context, and was wondering instead of that hacky workaround, is there any way to make my JFX application starts with no error.


lbreakouthd fails to launch with "libGL error: MESA-LOADER: failed to open iris" Steps to reproduce the behavior: lbreaouthd with lbreakouthd launches Framework laptop with intel graphics. Please run and paste the result.
keep an eye on the and tell me if anything goes wrong


Since the introduction of in (), derivations should use instead of to further reduce the usage of the attribute.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


NixOS unstable is affected by on Wayland. Steps to reproduce the behavior: signal-desktop on Wayland. No crash. Add any other context about the problem here. Please run and paste the result.
I am also getting a crash every once in a while on startup. Starting it again works so far and it seems stable after that. Don't know what to do about that.
I've fixed this locally by using the following overlay:
Apparently, Signal beta works again on Wayland.
Just adding a data point. Having Wayland disabled actually caused more bugs for me. Re-enabling Wayland via 's overlay helped fix my compositor crashing whenever I clicked on certain UI like "preferences" in the "file" menu. Currently running: with set to and have the following env variables set:


Steps to reproduce the behavior: Bisected: Introduced in
From the build log: What the heck is that meant to do? This test would pass if the reported size of the TIFF starts with a 7, a 9, or a pipe character, and fails otherwise? Surely this is an upstream gscan2pdf issue.
Issue reported to the gscan2pdf project: Since this should not be impacting the other features of the program, I think it's safe to temporarily disable that one test for that package on our side.
Disabling the test temporarily in:
With merged, let's close this. There's nothing we can do until upstream reacts.
Apparently upstream did update their test according to , but we need to wait for a new release containing the fix.


If gdm is enabled with Gnome enabled, gdm will crash and not load into the login screen after logout or reboot. This is due to gdm using wayland as the default. Once wayland is disabled in gdm, the login works. Steps to reproduce the behavior: channel nixos-unstable, "sudo nixos-rebuild switch upgrade-all" with Gnome enabled and gdm enabled in will hang at the gdm check point. gdm wayland in and the reboot works but with Wayland not working. Reboot into gdm with Wayland <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I just hit the same issue. After updating to latest nixos-unstable, the boot hangs just before login screen I think this is related to , at least the workaround posted there worked for me also
Would be relevant with a machine without AMD graphics and without KDE? As, I am running Intel's build in graphics and using Gnome. Also, I did find a "workaround" by disabling wayland in gdm then nixos-unstable will boot.
I managed to work around this issue with on GNOME Wayland. Graphic card: Intel Xe Graphics (TGL GT2)
Totally worked! Thanks and ! Should I leave this open as this is a bug or a new config that needs to be applied to 23.05?


Project description VMware OVF Tool is a command-line utility that helps you import and export OVF packages to and from many VMware products. A package already exists for Linux ARM and x86-64. VMWare ships package for macOS but, but support for it is missing from the package. Metadata homepage URL: source URL: license: unfree platforms: darwin
The main problem in my case is that I don't have an Apple machine nor somewhere to emulate one, so I might not be able to support this ovftool type.
Work in progress, doesn't function. I have a few questions on that PR about how to do this and not make it a complete mess.


Package name: organicmaps Latest released version: 2023.04.02-7Current version on the unstable channel: 2023.03.05-5 Current version on the stable/release channel: 2023.01.25-3 Notify maintainers Note for maintainers: Please tag this issue in your PR.


Building powerpc kernels (I only tested pkgsCross.powernv, but examination of the kernel source code suggests to me that 32-bit powerpc, and well as big-endian 64-bit will be the same) is broken since This happens because on powerpc, the kernel target we install is vmlinux, rather than any derivative of it like zImage. The kernel build system will strip when creating such a derivative image, but because we install vmlinux directly, we get an unstripped image. This means the kernel contains references to its build directory, which since that PR will be the $dev output. AIUI, 64-bit POWER boots via kexec, and a zImage is a self-extracting kernel ELF image, so hopefully the fix would just be to switch the kernel target for powerpc to zImage, and things will work again, and POWER users will get smaller kernel images as a bonus. I'm not sure about 32-bit PowerPC, but this might be helpful. If we can't use an *Image target for any powerpc targets, there is also a target called that we could fall back to, but let's take the opportunity to evaluate whether anything else is more suitable first, when we're changing this stuff anyway. Apart from powerpc, the only we have that uses vmlinux as its kernel target is a MIPS machine called the Fuloong 2.0. I don't know how it boots.
I'll handle this. I don't have big-endian POWER hardware, but pointed out that qemu can probably boot a BE kernel under emulation at full hardware speeds. So if that works I can take care of the 32-bit POWER (which is mostly BE) too.
For reference, I managed to get a working kernel derivation for Power9 with Just setting building a zImage without fully stripping it afterwards wasn't enough. There still was a reference to in the debug info somewhere.
Yep, very plausible that there are other references as well. We had for x86 and RISC-V, although that specific issue didn't apply to other architectures.
I'll dig into this this evening. thank you for the tip! Also putting this link here so I don't lose it:
Verified (after fixing a bunch of other things) that is affected too. Thanks again for the heads up Working on a fix.
Edit: I meant to post this .
Fixed by


The pkg-config file in pkg looks like this: The and variables are empty. The keyword is also empty. As a result, the flags returned by pkg-config are wrong and checking the version does not work. Note the empty and and that the package version is actually 3.0.1, i.e. = 3.0.0. and should point to the correct directories in the and outputs of the pkg.


Project description A cross platform mod loader for The Legend of Zelda: Breath of the Wild in CEMU. Metadata homepage URL: source URL: license: GPL3+ platforms: Windows, Linux
I actually have this packaged in my nur repo: , but I let it go out of date for a bit. (should get back to updating that ). You can test it out with The version I packaged works really well (or at least when I was still using it ) - it was just frustrating to maintain with all the patches & new dependencies, and I decided to hold of on merging to nixpkgs for now.
Maybe should be made instead?
Please test / .


Project description Metadata homepage URL: source URL: license: MIT and Apache 2.0 platforms: linux and darwin (might also work on other platforms) Additional Notes It's worth noting that appears to be updating off the branch with a re-created tag upon each "release". It may be the case that doesn't make sense to be in right now, but perhaps folks have ideas on what it could look like to update automatically. EDIT (17 Apr 2023): I suspect the package will go in . It's also worth adding the following note from the source URL's ...
Didn't try it out myself, but this may work
I'm getting close to publishing a PR actually :) Should be up soon.
Update: adding packaging to the upstream flake may be the best idea for now. Either nixpkgs will need to support Rust-based packages with nightly toolchains (unlikely and for good reasons!) or will need to be buildable, and intentionally so, not as a hack, with stable Rust (linked issue: ). The good news is that caching solutions exist and work in should provide a good bluepoint for where to start with an upstream contribution. Full Context: Fortunately, likely will not have the same issue being included in nixpkgs, so I am authoring a PR to add reindeer (issue: ).
As of yesterday, I have a flake available on my fork that you can use to consume the binary in your downstream projects easily. For now, consider this a simple workaround. I plan on semi-regular-kinda-ish updating it and rebasing on trunk, and eventually contributing it upstream; see also Flake usage is easy. Something like the following should work where you can use or inside your flake outputs to refer to it, and you can put it in your environment, etc: You can also get a binary in your with
As of , there are now buck2 binaries, thanks to the Meta team doing releases! They can be updated every two weeks easily. So that means you don't need a Flake, cache, or any expensive build steps. Please let me know if the binary doesn't work for you; I've done some light testing on NixOS, and it seems to work fine in a normal environment; if things are broken somehow, we can pull it or figure something out.
Two side notes: I will probably migrate the flake to a new repository, so that I don't have to keep my main development fork clean at the moment. We can probably close this now, I think.
Thanks for the help I believe does close this issue since is now in nixpkgs. Great work and thank you again :)


Project description is a cargo subcommand, which shows crates info from See their for an output example. Metadata homepage URL: source URL: license: mit OR apache platforms: unix, linux, and darwin


Package name: gnome-obfuscate Latest released version: 0.0.9 <!-- Search your package here: --- Current version on the unstable channel: 0.0.7 Current version on the stable/release channel: 0.0.7 <!-- 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.


Project description Perhaps it would also require a module to set the correct permission for /dev/uinput? dotool reads commands from stdin and simulates keyboard and pointer events. It works everywhere on Linux, including in X11, Wayland and TTYs. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: GPLv3 platforms: unix, linux dotool requires permission to to create the virtual input devices, and a udev rule grants this to users in group input. You could try: echo type hello | dotool and if need be, you can run: sudo groupadd -f input sudo usermod -a -G input $USER and re-login and trigger the udev rule or just reboot. See , but this greets the world: echo 'type Sup, Lads!' | dotool and this screams for three seconds: { echo keydown A; sleep 3; echo key H shift+1; } | dotool There is an initial delay registering the virtual devices, but you can keep writing commands to the same instance or use the daemon and client, and . dotoold & echo type super | dotoolc echo type speedy | dotoolc dotool will produce gobbledygook if your environment has assigned it a different keyboard layout than it's simulating keycodes for. You can match them up with the environment variables and . echo type azerty | DOTOOLXKBLAYOUT=fr dotool dotool was written for , which has a you're welcome to join. You can also send questions, thoughts or patches by composing an email to .


The script defined in contains a if it does not yet exist. The file name of the disk image is stored in the bash variable which is when creating the disk image. Thus, if contains a space, the disk image creation fails. The following is an easy way to reproduce the problem under macOS with a recent nixpkgs; not sure about a Linux example, but anything that triggers a VM creation via in the current directory should do the trick. and enter a folder with a space in its name: a VM via nix, e.g., (a recent builder VM for macOS). (will ask for sudo password for key setup) image creation is triggered and fails with the following output: The builder disk image for the VM should be created and the VM should be started. (Also seems like there is a minor typo in the error message: "Disk image does not exist, …".)
Good point, can you send a PR?
Sure, here it is. As far as I could see this seems the online place in the script where the variable was not properly escaped. A quick test via from a folder containing spaces worked as expected.


Regression caused by : on non-NixOS (in my case, Ubuntu 22.04), building the formats causes the following error Steps to reproduce the behavior: nix and nixpkgs on a Ubuntu 22.04 on some custom collection of packages. : call (after adjusting , because is not currently wrapped). Whereas calling seems to work fine, thus it's really the call to that messes up things. Formats should build, of course, and there should not be any mention of the impure ! also I don't know how to fix this one! Please run and paste the result. `
Yeah, I don't think we can fix this. I suggest a revert and patch properly.
In the meanwhile, I discovered my nix install (via the Debian package) couldn't sandbox properly. After removing the Debian package and installing nixpkgs proper, I could sandbox the build and avoid the issue. So this is in part a bug of the Debian nix package (because it does not sandbox properly). My suspicions are also on the function in perl, which calls (hardcoded!). That's my current best guess as to why the impure linker is involved. Maybe the correct solution to compile perl with the correct , if that's even possible... ? In the meanwhile, if non-sandboxed builds must be supported, we should definitely revert before 23.05 branches off.
Quick note: I am fairly convinced now that is causing problem because preloading libfaketime causes a glibc conflict. We should probably patch , or , in the perl Configure script so that perl calls a nix shell. if you know the appropriate person to cc for perl stuff, please do, I don't think I can patch perl correctly on my own.
The fact that the system function executes /bin/sh is governed by glibc. I remember this was discussed before, and there were issues with hardcoding in there.
Presumably a cycling dependency bash -glibc -bash, at a minimum. The lesson: is fragile and must be handled with care. Better patch fmtutil locally, like we do for mtxrun, to add faketime in front of the format calls. (Changing the perl configuration might still be doable, though, regardless of whether it changes the behaviour of . I'll give it a try.)
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


With the urxvtd service enabled on NixOS, the first instance of does not display anything, but keeps running. All following instances work as expected. This differs from the behaviour of not enabling the urxvtd service and just running manually, where everything works as expected. Set . Reboot and log in. Open a non-urxvt terminal and run from it. I'm running on XFCE with XMonad, and the problem has been reproduced on plain XMonad. System: (Gorilla) Nix version: nix-env (Nix) 1.11.6 Nixpkgs version: "" /cc
Uhm, I can't reproduce it with either bspwm or no window manager. I will try XMonad later. update: Just tested with XMonad and negative. Are you sure you don't have anything else interfering? Can you test it in a VM?
I just encountered this issue on a fresh install of . I'm also using xmonad, though it might be unrelated. On boot, shows nothing. Upon opening xterm and running urxvtc, no new window opens but nor does the command return anything; it continues to run the job. Now if I open another xterm and run again I see both a .urxvtd-wrapped and a urxvtc instance, and running urxvtc now spawns a new terminal window as expected. Earlier when I ran I got a torrent of warnings for collisions, I think between with-unicode3 and with-unicode3-with-plugins, even though I've never put the latter in my config. Don't know if it's related. I've since GC'd and cleared old profiles, and the warnings were not reproduced on my most recent . Edit: actually I got the collision warnings again, so that's still a thing.
I have had this too for a while now but I had forgotten about this issue. I couldn't figure out what's the cause. I'll try investigating some more.
Is the problem still there with 18.09?
Yes, unfortunately it's still here.
I looked at this on NixOS 18.09 under XMonad. I think the issue is that urxvtd is not compatible with socket activation. When urxvtd starts, instead of listening on the socket provided by systemd, it creates its own fresh socket file at the same path (), replacing the old one. So when you start urxvtc the first time, it hangs because it's connecting to systemd's original socket whereas urxvtd has created and bound to a different one. When you start urxvtc a second time, the issue does not occur since urxvtd is already running (urxvtd creates a new socket only once, when it starts up). To verify I used these shell commands: systemctl --user stop urxvtd.service systemctl --user start ps -ef | grep urxvtd # urxvtd is not running stat --format %i "$RXVTSOCKET" # prints the inode of the socket file urxvtc # hangs, kill it with Ctrl-C ps -ef | grep urxvtd # now urxvtd has started stat --format %i "$RXVTSOCKET" # socket inode has changed urxvtc # works as normal stat --format %i "$RXVTSOCKET" # socket inode has not changed Checking [rxvt-unicode source code][1] confirms that it intends to delete the existing file at . [1]:
I have submitted a to fix this by removing the urxvtd socket activation.
thanks for figuring this out! tiny nit-pick the link to source code is wrong.
whoops! Fixed now.


Package name: swayfx Latest released version: 0.3 <!-- Search your package here: --- Current version on the unstable channel: 0.2 Current version on the stable/release channel: not packaged <!-- 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.
c.f.


NetworkMiner NetworkMiner is an network forensics tool that extracts artifacts, such as files, images, emails and passwords, from captured network traffic in PCAP files. NetworkMiner can also be used to capture live network traffic by sniffing a network interface. Detailed information about each IP address in the analyzed network traffic is aggregated to a network host inventory, which can be used for passive asset discovery as well as to get an overview of which devices that are communicating. NetworkMiner is primarily designed to run in Windows, but can also be used in . Metadata homepage URL: source URL: platforms: linux


Builds ok on x86_64, but on aarch64-darwin it hangs every time at  Steps to reproduce the behavior: <details</detailsI'm surprised not to see other issues about this as it seems to be logic contained in a major package (pytest), so I wonder if it's a problem local to my system. I tried rerunning after and and outcome was the same. Please run and paste the result.
I can reproduce this and, in my case, it is caused by the test in pylsp-mypy. I do not yet know why.
I believe this will be fixed by I'm planning to wait a few days for a response from upstream before patching this in case the code has to change, but please feel free to pull it in earlier if you have a need.
Yes, that sounds suspicious -- I'll try to build the PR and report back.
Sure enough, that patch does the trick.


So I today I spawned a machine with and satisfyingly the directory was generated with all of the certificates etc that taskwarrior needs, including the clients' certificates. I noticed that the users' keys located at are owned by root with read only permissions for the root user alone. No matter what are and . I'd like to enable the group read those client keys, as well as the file so that I can configure a client easily. Thankfully the group can read the file, but not the client keys. The manual indeed explains that the command: Could be used to get those keys, but I'd like to use syncthing for that to automate the process even further. I got a bit lost while reading the . Specifically, I'm not sure why does always works in the following umask: I mean, ~why not~ - a solution is suggested in . A word of comment will be appreciated. cc .


Package name: electrum Latest released version: 4.4.4 <!-- Search your package here: --- Current version on the unstable channel: 4.4.0 Current version on the stable/release channel: 4.4.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Reporters Note: Tried the update locally and got the error Looking at the diff on the electrum github I see the substituteInPlace pattern will no longer match: In:
PR in


Hello I was trying to review just now the source code that 'rstudioWrapper' uses. When I hit source from nixos-search I was redirected to this link However after checking in , I noticed that the expression that runs 'rstudioWrapper' is this one I'm not sure why this is happening, nor if the report should be here or in nixpkgs. In case I made a mistake, I would appreciate if you let me know so I can open another report. Thank you very much for nixos-search, I can't imagine the Nix experience without this amazing search engine.
This is indeed a nixpkgs issue as nixos-search just links to . The default position is determined by , so things like usually get their position reported at the definition of rather than at its call site. Maybe that could be fixed by making use the position of one of its arguments, but I don't think there's anything to be done in the case where the second argument is empty ().
Oh, that was fast. Thanks for your help! I stay tuned if I can/should do anything.
Hello again! I'm just seeing that your PR has already been merged. Do you agree if we close this issue, or is there anything left? nix-search unstable already perfectly references rStudioWrapper! Thank you very much for your help.
This is probably not completely solved yet (uses of without arguments would still have incorrect position information) but there's nothing actionable left to do so we might as well close it.


As a newcomer to nixpkgs and MacOS user I've followed manual how to install . Unfortunately second command in tutorial which is supposed to list available Haskell packages fails to execute: This was broken by refactoring done by in the commit: Run command on MacOS. System: OS X 10.11.5 / Darwin 15.5.0 Nix version: 1.11.7 Nixpkgs version: 17.09pre102737.


The nextcloud package set offers apps, that have licensing information attached, but not exposed as part of their meta attribute. Also, there are some apps, like news, where the licensing information says , which requires clarification. This needs to be fixed.
Thank you for opening the draft PR in order to fix my mistakes and broken packages. I'm sorry for the bad communication and the inability to resolve this serious issue. Fixing this for Wordpress packages and themes (wp4nix) and Nextcloud apps (nc4nix) in a foreseeable time exceeds my skills and competence. Therefore I would like to offer to add a flag to these package sets and remove them for the next release 23.11 if it's not resolved by then.


Project description GoatCounter is an open source web analytics platform. Metadata homepage URL: source URL: license: EUPL platforms: unix, linux
I searched issued but not pull requests so I missed , should this stay open until that's closed?


defaults to the tmpfs defaults: 50% of RAM. What do you think about making it configurable? tmpfs has no real overhead when not used and just like normal memory, it can be swapped out if memory gets tight. I have a hp microserver n40l with 8GB RAM and i can't rebuild the linux kernel with , as my /tmp fills up even though i have a bit of RAM left.
I know i can do this instead (copied from one of my machines): but I don't like having a nice option for this, and still using the "manual" way.
since you have already found a solution for this, have you considered opening a PR?
i don't find that conversation atm (discussion was probably on irc?). anyway, my "fix" was too liberal in it accepts as input (bool and string) and didn't reuse the original systemd template/unit file. feel free to reuse this as a basis for your own pr or give me pointers how i could do that in a few lines and without messing around with the option. maybe i'll try a pr with the solution, but thats more of a hack. thanks for the reminder, that this is still an issue.
Why is a hack?
because it doesn't automatically get new features from the upstream systemd unit file. that was the main part of point two. whenever systemd gets a new feature, the unit files in every distro get automatic upgrades - just nixos would need manual intervention.
Oh I wasn't aware how this is currently done. Is it realistic to expect new "features" for a filesystem mount? Maybe my imagination is lacking, but I have no idea what that might be.
see
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 .
This still seems like a desirable feature, especially since nix builds happen in /tmp.
I marked this as stale due to inactivity. →
Any activity on this? I've a build failing, even though boot.tmpOnTmpfs is set to false
have you tried increasing size of /tmp ? eg
Where is the RuntimeDirectory located? I thought that should be , which on my system is pretty big: I'll try to add that option to my config, not sure I fully understand what it does though, is it documented in more detail somewhere?_
sorry i made mistake in my post when i mentioned because its really not that one on my system it's You can look up systemd documentation for RuntimeDirectory
Rebuild nixos and reboot.
There is now an option for this:
For those who end up here, my problem was that for some reason was set to . Tip: just change the value and inspect the result with .


Some cuda packages come with vendored copies of libraries that are already available in nixpkgs. These vendored libraries still require patching their Runpaths, their presence reduces determinism, and breaks "deep replacement" (i.e. nixpkgs' feature allowing to ensure that everything in a package set uses the same revision of a dependency). For instance, ships , which otherwise is available as: Cf. Tasks [ ] Look into deleting these vendored libraries and re-linking their reverse dependencies against nixpkgs alternatives


Project description A video game ROM collection manager to help filter, sort, patch, archive, and report on collections on any OS. Metadata homepage URL: source URL: license: gpl3 platforms: linux


There are syntax elements, like which are used in the manual but undocumented in the . the generic syntax is document , but a few more non-admonition variations have been implemented recently that aren't yet documented in the manual. Originally posted by in


the ruby gem tzinfo exists in two different versions/branches which are both maintained. the branch does not contain the file referenced by nixpkgs, only 1.x does. Ref: Extract from pkgs/development/ruby-modules/gem- I fixed it by overwriting tzinfo (again!) but this is not a good solution :/ cc System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run )
Hmm. I don't remember by heart, is available? If yes we could switch based on the version. Pseudo code:


webUISupport is needed for the command. However, enabling this flag fails the tree-sitter build. Steps to reproduce the behavior: to your favorite checkout of nixpkgs A successful build. I'll give you a section of the build log instead: Please run and paste the result.
I still get this error with tree-sitter 0.20.9 in a Nix flake. Did setting the emcc cache outside the nix store fix the build for you?
If I try to reproduce it, I get this error: Which looks similar, but I think is a distinct issue. I do not think this is related to the emcc cache. I think it's best if you open a new issue for this. The emcc cache is not set in the Nix store btw, it is set in a nix build directory, wherever that may be. You can generally not set the emcc cache somewhere outside of the nix sandbox.
Sounds good. Thanks for the clarification. Wasn't sure if there was a setting I was missing
I've got a PR out (see above) to fix this new issue.
Awesome. Thank you


Project description python docstring generator <!-- Describe the project a little: --Metadata homepage URL: source URL: license: bsd platforms: unix, linux, darwin, ...


I see that the custom CPU scheduler, zen's main feature is disabled: This raises a question: does nixpkgs' zen actually differs from the default kernel or nixpkgs disables all the customizations by applying the same config as to the default kernel? Moreover, nixpkgs provides the -lqx variant with the same config but the main difference between -zen and -lqx variants is the config: liquorix provides a pre-defined config with its Debian/Arch packages and when I see lqx in the repos, I expect nixpkgs to use it as well as there's no source code difference. The -lqx variant seem to be poorly maintained in nixpkgs in general, it lags behind -zen variant (6.4.1 vs 6.3.11 in current nixos-unstable). Steps to reproduce the behavior: -zen should have its features enabled more or less, the -lqx variant MUST use (and probably be available only for x86_64). See the for example. Would be nice to have variants with different schedulers like the AUR package allows, preferably pre-built on Hydra (well, I don't have a powerful enough hardware to build kernels).
It might be a good idea to also have a xanmod variant built with .
I created a PR that should fix this: I took a look at the Arch config for -zen and it looks like it is basically the vanilla kernel with and some tweaks to the RCU/Preempt/tick. So this is what I did above. For the -lqx variation, I activated the PDS process scheduler, BBR2 and other tricks that seems to make Liquorix kernel (according to the site: ). This is not exactly true, the release of the -lqx variant generally lags between major kernel releases, so while -zen gets to X.Y.Z, -lqx will stay in X.Y-1.Z for some weeks (I imagine for stability purposes, but I am not familiar with upstream). This will be difficult, because we can't simply take its configuration as-is. If the current approach in the PR above is not acceptable, I would say it is better to just remove the -lqx from nixpkgs. We already don't seem to have that many users of the current variants considering you're the first person to note that we are compiling the packages without the customizations. So unless there is really a strong demand I would say let's not do so and just keep 2 variations of this kernel that should be enough for most users.
It's acceptable as a first step but why can't we?
I guess only the minority checks actually? I periodically see in Arch groups how people try -zen thinking they get all the features for better responsiveness but don't see a difference and don't even think about checking what scheduler they run actually.
It would be really difficult to use upstream configuration as-is. I mean, I don't think it is impossible, but I definitely don't want to be the person to do so. What I mean is mostly that I don't think most people care anyway. Even users of those custom kernels doesn't seems to care too much if they're actually using a custom scheduler it seems, considering again you're the first person to note this issue and this kernel is in nixpkgs for a long time already. So considering that nobody is that interested in the first place I think adding another variation of those kernels is too much. We definitely can do in the future if there is enough people that wants those though.
What I mean is they do care, it's just they don't know how to check. They see -zen and believe they get all the features out of the box.


Project description Virter is a command line tool for simple creation and cloning of virtual machines based on libvirt Metadata homepage URL: source URL: Blogs: , license: Apache v2 platforms: Linux only written in: go Thanks a ton!


When attempting to configure the integration I get an error in Home Assistant Steps to reproduce the behavior: to to configure integration from Home Assistant UI Able to configure <!-- 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.
The package does not eval on master right now, because of a dependency being flagged as disabled for python 3.11. Though I'd be surprised if that is your issue. nix-replhome- error: … while evaluating the attribute 'drvPath' at 221| in commonAttrs // { 222| drvPath = assert condition; drv.drvPath; | ^ 223| outPath = assert condition; drv.outPath; … while evaluating the attribute 'drvPath' at 221| in commonAttrs // { 222| drvPath = assert condition; drv.drvPath; | ^ 223| outPath = assert condition; drv.outPath; (stack trace truncated; use '--show-trace' to show the full trace) error: cherrypy-18.8.0 not supported for interpreter python3.11
Regardless, at least makes evaluate.


The Haskell Hackage database allows distros to report which packages they ship, and include a link. Right now, it seems that nixpkgs reports all haskell packags, including broken ones. This makes for a bad user experience – I might see on hackage that nixos comes with a certain package, and then happily go ahead trying to use it, only later to get the dreaded error message. Same actually for repology, reporting packages as available that we know do not build is not great.
We intend to support all package. We just need haskell maintainer
Oh, absolutely! Maybe I shouldn't say “supported” but “available”.
No, we don't. We only intend to support packages which have value to our users. Hackage is append only and contains a lot of dead or niche packages.
I agree this should have been fixed long ago.


VSCode/VSCodium's desktop icon (specified in the file) is set to . On the icon theme (the default dark icon theme that comes with Budgie desktop on NixOS), this makes it look like a generic text editor, and not the respective application. The issue appears to arise from how both apps use the same desktop files that were inherited from :   NixOS w/ Budgie desktop Icon theme to Qogir/Qogir-dark VSCodium/VSCode app list VSCode should use the icon VSCodium should use the icon ! My NixOS install is running in a VMWare VM.


I use the following listing in to install a custom keyboard layout: This refers to files in the following structure: This worked until recently (last updated a few months ago), but now fails to build: <details<summaryFull trace</summary</detailsCommenting out the line causes the same error but for . Adding in plausible files in the suggested places also doesn't fix the issue. Steps to reproduce the behavior: up the configuration as above. . The system successfully builds, and I have access to the custom layout. <!-- 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.
Sorry, I forgot to notify maintainers, but I think it's just
This breakage happened with with the update of as they have switched to the meson build system.
Thanks, that's really helpful! I suppose I'll revert to before that merge for now (though I'm finding it hard to find the list of good commit hashes). Do you know any other workarounds?
You can use . that does not have those changes. For a list you can look at in the "Input changes" column. That is a log of the "nixos-unstable" branch, for which the binary cache has been filled after a few tests have been run.
The script that patches the makefile to include the extra layouts need to be updated.
Can you test if your layouts work correctly with ? I a test for a basic file but I haven't tried other types.
Works fine for me but I also only use symbols
Fix merged, you can track the progress to nixos-unstable .


Steps to reproduce the behavior: X 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.


Project description EteSync is a "secure, end-to-end encrypted, and privacy respecting sync for your contacts, calendars, tasks and notes." Since GSoC 2020 KDE supports it. automatically detects if it is installed and builds the appropriate modules. Metadata homepage URL: ("build from source" link points to a site that is gone) build instructions: source URL: license: BSD-3-Clause platforms: unix, linux, darwin, ...


JetBrains IDEs are currently at which is kind of confusing because the packages here aren't all under name. For example WebStorm, PhpStorm, PyCharm and so on - these are properties of JetBrains. Therefore I think it will be good to move all them under and rename to .
Do you want to make a pull request?


tries to send (empty) md5 hashes to fetchurl, which doesn't accept md5 hashes it seems Steps to reproduce the behavior: enter the following command: The firefox plugin builds successfully <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --git revision tags of both NUR and nixpkgs are in the command given above
Can you try , I tested with your repro cmd changing to in nixpkgs src with the patch.
This works correctly, thank you very much!


Contributors working on improving the nixpkgs manual would be redirected to the . This section is not up-to-date with all the syntax features supported by , forcing contributors to look for use examples over the whole manual. The same markdown syntax is used to write and generate the NixOS manual. However, this manual does not make any mention of the supported syntax. This makes it hard to contribute to the NixOS manual with relative isolation from the nixpkgs manual. Update in Nixpkgs manual to include reference material and examples on all the syntax features supported by . Link in Nixos manual for completion. [x] remove references to in the . : [x] remove references to in the . [x] add a redirecting to the syntax section in . [x] add reference to lack of support for [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support [x] add reference to support () () )


The wrapper only has , so the corresponding where would check for manpages is absent. don't have regular vim installed install something like 09pre104936.
You can find a fix in /


Hi TLP shows the following in output: Anything to do with it? Thanks. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run )
I believe the tlp module could be made to set for those systemd units
Fixed, thanks for your report!


NixOS specialisations are supposed to have their own entries in the Grub menu for previous generations according to the . However in practice that is not the case. The older generations do not hold any boot entry for the specialisations, but only the default entry. nixpkgs: I am not sure, whether to update the wiki to correctly mention current behavior, or whether to fix the grub module to generate entries for specialisations for older generations. <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions
Fixed by .


Project description From the project page: A tool to sign PDF files with Linux support. Why There appears to be a lack of applications that run on Linux and allow for attaching free-hand signatures to PDF files in a good way. (Non-)alternatives include: Xournal and Xournal++: Allows free-hand annotations but not saving those for later use. Allows inserting images and .pdf files but will rasterize them rather than retain the vector graphics, resulting in lower quality. LibreOffice Draw: Allows inserting images and .pdf files but will rasterize them rather than retain the vector graphics, resulting in lower quality. Okular: Allows free-hand annotations but not saving those for later use. Allows inserting custom saved stamps, but these will not be visible in other PDF readers. Evince: Allows certain kinds of annotations, but nothing that can look like a free-hand signature. pdftk, Ghostscript, and other command-line tools: Allows superimposing .pdf files, but not interactively selecting where. Metadata homepage URL: source URL: license: MIT platforms: linux
Working on it


Trying to set up an OpenVPN connection using the NetworkManager gui (in plasma5, but in theory it should be the same as in gnome, right?), and connections are failing immediately after a successful connection with the following error messages in syslog: Then the connection starts again and it repeats forever. System: 17.03 at Nix version: 1.11.8 Nixpkgs version: 17.03pre
Does the nm-openvpn user need to be to the unix group for this to work?
The connection reset in my log snippet may actually be caused by but I suspect that the dbus rejected sends are still a problem.
Any news on this issue?
I don't think I have encountered this bug for quite a while, but I also haven't been using OpenVPN recently. Are you still seeing the same error messages?
I did not, just doing triage. I'm going to close this, but feel free to reopen it if it surfaces again.


is failing to remove requirements as requested by the setting of . Attempt to build Upon building: Tested on . to remove the dependencies as specifies. n/a n/a Latest committers to python-relax-deps- <!-- 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.
Some debugging: I'm fairly certain this is due to a naming issue with the whl. pkg_name () is set to based on some print-statement debugging. But the actual wheel that is produced is . Why are these names different? Why isn't the wheel named ?
Probably because the wheel name is based on the package metadata. Maybe we should just ignore the version during the matching?
Yes, we should.
Created a PR:
Closing now that has been merged.


Package name: muse-sequencer Latest released version: 4.1.0 Current version on the unstable channel: 3.1.1 Current version on the stable/release channel: 3.1.1 Notify maintainers No idea who the maintainer is:


System: 17.03.917. (Gorilla) Nix version: nix-env (Nix) 1.11.8 Nixpkgs version: "17.09pre105314."
cc


We got theses reports of Kubo panicing on startup due to probably an empty field This is a bug in our software however I belive this is also a bug in: Because a Kubo daemon without an API listener is borderline useless, your choice to change to a unix socket () makes sense however I think some default got lost and now it is set to . Given I am not a Nix user myself I got help from to fill in the template, thx :heart:. Steps to reproduce the behavior: to notice it's failing with a panic. After installation Kubo daemon should start and the RPC should be usable by a permissioned user. Please run and paste the result.
/cc (I forgot to fill it in the template and I don't belive GH pings peoples from edits)
Weird that it works on my machine and in the NixOS tests. One of the NixOS tests only has and options set. does quite a lot but I didn't see anything obvious why this should affect the API settings. But maybe it does make a difference and maybe I specified some additional option on my machine makes it also work there. I'll try to reproduce it with just the enable option set in the next couple days. On one machine shows that the field is set to and yet Kubo starts without a problem and can be seen in the log. According to a comment at the top of, , "Enabling this [socket file] will completely override any API listeners configured in your config.". NixOS enables this socket file and overrides with (which is ) plus whatever the user has set in . What I don't know is how systemd communicates this information to Kubo but this seems to work. So in conclusion, I would think that setting the field to in the Kubo config doesn't matter because is enabled, which should override this and specify a socket for the API.
Thx I wasn't aware we even had this feature (or that you could use systemd to configure application sockets in the first place). We have a simple incorrect assumption which is panicking since kubo is configured without listeners. However this is fed by which tries to load as you linked. So if you have a but use something like it should work (AFAIT). I can't test experimentally that feeding the API through systemd works right now, I'll report later, but it seems to me that the like config is not applied somehow.
I was able to reproduce the problem. Maybe I just need to order the unit after the two socket units. I'll take a closer look in the following days when I have some more time.
This happened to me too on first installation, the reason was that systemd couldn’t bind port 8080 because it is already in use by another service, then started Kubo anyways. So my theory is that Kubo checks if there was a socket made available by systemd and if there was none falls back to trying to read the listen address from the config (which is then null) and then panics in the observed way. For anyone else affected by this, run and check if both sockets were correctly bound when Kubo crashes in this way.
I created , which should fix this.


Steps to reproduce the behavior: on nixos-unstable I believe this is related to <!-- 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'll need a similar fix like the ones in Wasn't caught in staging because it's marked insecure


Starting this week, we happens anyways. [^1]: will enable it, with support by Unless this causes major problems, we intend to keep this enabled permanently. Please use this issue to report any problems you encounter because of this. The and branches that are consumed by Hydra. Please contact the release managers as they will be to the exception list. In general, we expect that the PR workflow will be enough for the vast majority of cases. This change was originally proposed almost 3 years ago with closed when direct pushes were way more frequent at . Very recently a new attempt was started with , for which computed that nowadays of commits are pushed directly. The RFC was struggling to get enough shepherds, when rightly that such simple decisions shouldn't be blocked, following up with the proposal to just enable it and try it out.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
nixos-release-managers already existed
Note that releases should also work without direct pushes, which is being discussed in , so this exception should be removed in the future
Link is 404.
Thanks, fixed now by restoring the RFC's branch
that it looks like PR's can't be merged anymore when a committer requested changes (though it seems like those reviews can be dismissed? Edit: Confirmed, can be dismissed), additionally auto-merge seems to be available now: ! It doesn't seem inherently bad, but I did not expect that to happen.
"Require approvals" can be disabled. And indeed, depending on the configuration, committers can also dismiss a review.
I'm pretty sure that setting is not enabled. Indeed as an example, was merged 1 hour ago (when the setting was already in effect), and it was merged without any reviews. The good thing is that dismissing reviews does allow merging again, even if it's your own PR. And even better: To dismiss reviews you have to give a reason, I tested this here:
Fyi, we do have the option to turn off allowing auto-merges, see .
I think we should disable the auto-merge feature because it works only based on the reviews and completely ignores the OfBorg status. And until we have more solid CI we cannot also require CI checks to pass before merging.
I turned off auto-merges.
Meh. I don't oppose this policy, but I don't like how this decision sidesteps the RFC process. Does this imply proposals can be tacitly approved if they don't get enough attention? It doesn't seem right.
for the record, I'm fine with that and I withdraw my skepticism :) The problem I had with the previous behavior was that there was no way to override it (and from my experience almost every rule tends to have an exception ;-) ). I haven't checked it so far, but if it's possible to dismiss now while having to provide a reason for that seems good to me, thanks :+1: OK with this one being pinned globally, my other issue is also resolved, this provides reasonable visibility for each committer. IIRC we haven't had notable config changes in the repo for a while and I'm not sure if there are follow-ups planned to this, but for the future I'd like to suggest to always communicate it via a globally pinned discourse topic (and perhaps even cc all of the committers in $github_issue).
I know it looks a bit like we pulled a Flake again, but: The change does not have any long-lasting API or user implications, it can be reverted at any point without problems The change has a very low negative impact, of commits were direct pushes Meanwhile, the change has a significant positive impact, especially for security Considering this, I don't think it's necessary to have an RFC for this, because it should be an uncontroversial change, and indeed, we haven't seen any good reason in to not do this. But also a big argument is that going through an RFC for something so minor distracts people from more important problems to fix. Not having to maintain this RFC for months frees up time for me to e.g. focus on implementing accepted NixOS/rfcs, which is considerably more impactful.
Closing as this was up long enough


php is unable to find datadog- (and it's normal) Steps to reproduce the behavior: a shell with php and datadogtrace extension php.withExtensions ({ enabled, all }: with all; [ xdebug curl opcache openssl datadogtrace]) nix-shell and run php -v display "Warning: PHP Startup: Unable to load dynamic library '/nix/store/qi72nhxwvbysg35nbvf89q3ywad46xyc-php-datadogtrace-' (tried: /nix/store/........;" and the extension isnt' loaded the extension is well installed but php configuration is looking for a wrong one (the original should be named and the package is looking for
Thanks for creating the issue :) Fixed in
You ask me for that i think it's normal, it's a minimum :) NOw we just have to wait to make it work so ? have a nive evening (i'm in france) Le mer. 16 août 2023 à 21:29, Pol Dellaiera écrit :
You can monitor the progress of this PR by using the following tool: . If you are using Nix tools from the branch, they should already be available to you, but they will need to be compiled on your machine. This means that you'll have to wait for the compilation process to finish before you can use them. However, if you can wait for one or two days until this PR reaches , the binaries will be hosted on . At that point, they will become immediately available, and you won't have to deal with the hassle of recompilation. Greetings from Belgium.
no probleme to compile, l try !!! yes ! [image: ] [image: ] Le mer. 16 août 2023 à 21:43, Pol Dellaiera écrit :


outputs something like "187183230175148230" instead of Chinese when it should output Chinese. Steps to reproduce the behavior: of the terminal use a command similar to the following Can output Chinese normally <img width="803" alt="image" src=""The terminal is the one that comes with the gnome desktop. <img width="803" alt="image" src=""


Project description Enable to show workspaces. Metadata homepage URL: source URL: license: mit apache platforms: linux
I'm using Yambar on the unstable version with the + It's displaying workspaces correctly.
Thank you, didn't think to check unstable :~)
Ah I think I forgot what this issue was about, I'm looking specifically for packaging of a rust binary that listens for workspace info from hyprland's IPC.
Alright, I'm currently working on it. !
TYVM!


Dopewars is a game simulating the life of a drug dealer in New York. The aim of the game is to make lots and lots of money... unfortunately, you start the game with a hefty debt, accumulating interest, and the cops take a rather dim view of drug dealing... <!-- Describe the project a little: --Metadata homepage URL: source URL: license: GPL-2.0 platforms: Linux, Windows, MAC


Steps to reproduce the behavior: package 'grapejuice' Fixed by adding to propagatedBuildInputs Please run and paste the result.


Salmon is a bioinformatics tool to produce a highly accurate, transcript level quantification estimates from short-read RNA-seq data. It's mostly written in C++. There's a similar tool already in nixpkgs (Kallisto), but they both have a few unique features, so packaging Salmon is still useful. It's also quite a popular tool. homepage URL: source URL: license: GLP v3.0 platforms: linux, others?
I started packaging it, and made good progress. It's a way for me to learn Nix, but may need a few pointers to get it done
Open a draft PR, then.


calibre-web failed to start Steps to reproduce the behavior: -rebuild switch -u calibre-web The service start successfully, and no error occurs. 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.


fresh/clean install. edi the config file to add a package (in this case an editor) - but no editor is easy to find in the initial config to edit later the config (this is called the chicken and egg problem?) by the way - the manual, when mentioning the config file, point out its full name (including the location in /etc/nixos). this is not obvious when you run nix the first time! (This happens with all reasonable NixOS versions — )
is an editor, . , you can or something without editing config, then, if desired, remove the editor from profile when it is installed system-wide.
thank you - i did not think of nano. i was looking through the menus and did not find any; of course, nano would not be listed there. perhaps you add a comment to avoid stupid questions like this from newbies trying to use your interesting OS.
Let's hijack the issue to describe the real problem then…
While we are on it we could also think about adding an option in nix that installs your chosen default editor and sets the env accordingly.
good idea! for newbies, give some hints (e.g. gedit or similar)
Perhaps add to the template? But I saw that we also have and .
I suggest we deprecate.
add one of the simple editors as well - gedit, mousepad or one of the other graphical easy ones. It is important to have a very low entry threshold to capture new potential users. Something like the 2 second rules on web pages: if the new OS does not work out of the box for the newbie, it is dumped...
I'm all for making editing text files easy, but I'm not sure what good it is to set EDITOR to something with a gui. I think a user that might need help with editing text files will install a desktop environment that presents it's default editor to the user by itself. On the other hand, a user might try to do something like ` because they pasted it from some web page and unknowingly run gedit with root, making their system insecure.
What makes it more insecure and using an terminal-based one with root privileges?
is expected to point to an editor that works without X, whether run as root or not. uses and is expected to also work in the system terminals, independent of whether any X session is present.
I'm all for setting EDITOR to something sane like by default and for generalizing it similarly to X11. I don't think this argument really applies to NixOS. Any OS that requires you to edit some configuration files before you even install it is not for a newbie unless that newbie has some interested IT personnel around. I imagine it could be possible to make a usable GUI for with text lenses (in Haskell), though. But, in general, good installers (like Debian's) take a lot of effort to produce and yet most people never ever install their OS and most people that do install their OS could have just learned the shell commands.
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 .
I think we should include nano in our that we generate.
Would be the right place to change that?
I marked this as stale due to inactivity. →
yes.


Want the latest 1.3.0 dev release of pants (to get a particular bug fix). Just running pants w/in nix-shell w/ trying to use the latest version. System: OSX Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: "17.09pre106045."
Fixed in


Package name: wavebox Latest released version: Current version on the unstable channel: Current version on the stable/release channel: (doesn't seem like the has anything to do with Wavebox 114 to 116?) Notify maintainers Note for maintainers: Please tag this issue in your PR.


Project description <!-- Describe the project a little: --official sostitute of nimlsp Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ...


Project description The missing backlight auto adjusting program for Linux. Metadata homepage URL: source URL: (zip file) license: unknown platforms: linux virustotal:
I feel like shaving a yak. I'll take this.
Actually.... among other things the source here is a pain and basically impossible to make reproducible. Pretty annoying so I shall email the author.
here is a package in the interim.
fyi, I found the GitHub repository
Oh, nice. Still needs a license though before we can include it.
Not a blocker from my point of view. Package can be till the licensing situation is clear.
Author is on it re both of these things, btw! I would just give him a day or two.
It's now MIT licensed.
PR filed.


CMake seems to use ps command internally, but looks like CMake in nix on darwin can not find ps command, so it complains with message "sh: ps: command not found." (very many times) Although this does not seem to harm build, it is desirable if this can be solved quite easily by some simple patch.
I found a similar problem report in macports. Shall we include /bin/ps visible in cmake environment in darwin systems?
Is there no way to hard-code the path of into CMake?
isn't actually in .
The relevant code in cmake is I believe. The package on contains the Apple ps. I'll likely get it building as part of my revamp of the darwin stdenv, and if I'm feeling particularly charitable I might even hook it into cmake. In the mean time, I'd probably just leave this alone, since I don't think we're far off from having a sensible darwin stdenv.
We definitely can't use procps on Darwin since it doesn't have /proc. Also, these warnings are not always harmless: MySQL's startup scripts won't work unless it has ps in scope during the build process. Right now the workaround is this
This was fixed as part of the new darwin stdenv.


Project description can produce completions for a range of shells, including Bash. These should be integrated with the pijul package to improve usability. Metadata homepage URL: source URL: license: gpl2 platforms: all


Project description Compute metrics on Python code (e.g. cyclomatic complexity) Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin


We need to propagate the pth loader so packages using us process our pth files, but it makes no sense to have the pth loader itself in a pth file.


honk-initdb.service attempts tu run even though already exists, causing it to fail and prevent honk.service from starting. I think honk-initdb.service is supposed to be skipped since already exists? Please run and paste the result.
Hi, Thanks for the bug report. That's weird, because that service shouldn't run since the file already exists. I will try to investigate during the week.
Do you know if there is any way I can make honk.service believe its dependencies are met, as a workaround?
What I did precisely in I have no clue why this is not working yet.
I pushed a PR here: Could you try it and let me know if this is fixing the issue ?
Dear is your issue fixed now ?
Ping ^^
The condition seems to work but the issue remains?


Package name: cryptomator Latest released version: 1.10.1Current version on the unstable channel: 1.9.4 Current version on the stable/release channel: 1.8.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.


Package name: rio Latest released version: 0.0.27 <!-- Search your package here: --- Current version on the unstable channel: 0.0.19 Current version on the stable/release channel: N/A <!-- 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.
Seems one of the dependence of depends on which not entered master yet (see ). I'll handle this once it gets ready.
Not sure why it requires it. Maybe removing this requirement?
And it's an critical component that could not be remove.
1.72.1 merged into master
:+1: Looking forward to this as well. Hopefully fixes
Still not merged into master, merged into staging-next though.
1.73 has been merged into master.
I sent the update


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