A small difference in the dependencies used by aider and nixpkgs causes aider to crash. aider 0.56.0 something should get a stack overflow See <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
was closed by mistake so opened this
Thanks for opening this issue. Discussion started here It is clear that v1.44.22 of is what causes the issue but I'm not sure what could be done. maybe you have an idea?
There is an open issue in the repo, we have to wait for the dependencies to be updated upstream unfortunately. On the next update of this dependency ill be sure to try to run aider. Sorry for the inconvenience !
Why don't you use ?
the issue on aider's repo was closed the fix is to not use the wrong version of litellm :sweat:
it's not so simple for python packages. each one is a forest of carefully balanced dependencies.
Latest aider update matches with the latest litellm update, so we should be good in a couple of days


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


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


The final merged version of isn't building. Just build with the initial configuration that would give on a UEFI machine, along with: Build successfully and boot into Dom0 on next reboot. <img width="1201" alt="image" src=""During the progress of , the issue isn't happening as of . Might be a regression happened in the last few commits before it's merged. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Whoops. That's my bad. Will make a PR in a few.


Package name: paperless-ngx Latest released version: 2.12.1 <!-- Search your package here: --- Current version on the unstable channel: 2.11.6 <!-- 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. --


No desktop file is installed when installing httpie-desktop. Steps to reproduce the behavior: httpie-desktop. find it in the application list of GNOME. Find it in the application list of GNOME. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


python27Packages.faulthandler fails to build on the unstable channel Cc () The output shows test failures due to regular expressions not matching. E.g. It seems that the tests are expecting to see in the message, while the actual error says . If it's just that, I hope that it would be easy to fix the build. I am happy to help if given some guidance. Full output: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs:
This is an upstream issue. See similar issue Best write them that they should also accept , , etc. Then you can open a PR here that adds a patch to the derivation.
Thanks, will look into that. It probably makes sense to keep this issue open to track the upstream one though.
Note that a patch is available ( ), it may make sense to apply it (e.g. done for Fedora ) while waiting for a new release. I am still happy to try and do that.
I don't think that patch will work. It accepts but not .
Sorry, I missed that :(
I opened an upstream PR: And I applied the patch in Nixpkgs:
fyi has now been merged and a release is pending (see )... hopefully we won't need the patch after that. Thanks everyone for your work!
I removed the patches in .


Steps to reproduce the behavior: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hydra can reproduce:
I tracked down the potential source of this failure, and am working on a fix. These builds take 30 minutes for me though, so it's slow going.
Please see for a fix. Testing appreciated.
Thanks for the quick patch. EDIT: My way of installing to profile didn't pull the fix, I'll see if I can figure out a way to do it properly using the pr review package
Builds and runs... seg faults as soon as I load a model, but that's an AMD driver thing (whole WM crashes)... Ship it :laughing:
I did see some segfaults, but was able to restart and get it to load on my 6700xt. “Glad” to know it’s known and common.
Nice! Thanks for this - excited to see it roll into unstable soon. Ollama seems to always have some issue - is there a "working group" that has some focus on this program and nix? Anyway, thanks again!
The problems with crashing aren't nix problems, they're crappy amd driver issues. It doesn't crash if you don't load models close to the max vram available... obviously it shouldn't crash if you do, but amd... so yeah


It would be nice to see packaged such that at least an executable is exposed.
How about doing it yourself? Have a look at the and at the many examples in If you have questions, just ask them in this thread.


fails with the following error since #diff-: on master The systemd build system changed to meson but the systemd-cryptsetup-generator was not updated.


Neomutt's bundled tool is unable to find . We should probably replace that string in the perl script. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:


I have a Samsung M2022W (usb) that works on a raspberrypi using raspbian (2017-11-29-raspbian-stretch-). I had to pick the ML-2160 driver in CUPS 2.2.1 as recommended by On NixOS (cups-2.2.2): [nawal nix-info system: "x8664-linux", multi-user?: yes, version: nix-env (Nix) 1.11.16, channels(nawal): "nixos-17.03-17.03.1082.", channels(root): "nixos-17.09.3149.", nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs If I use services.printing = { enable = true; drivers = [ pkgs.samsungUnifiedLinuxDriver ]; extraConf = '' LogLevel debug ''; extraFilesConf = '' FileDevice yes ''; }; and pick the same driver, I get garbage printed out. I tried to track down the ppd on raspbian, but only found: pi $ grep 2160 /usr/share/cups/drv/splix- ModelName "ML-2160" PCFileName "" and (i.e. it generated the ppd when I installed the printer apparently). On nixos: [nawal | grep 2160 /nix/store/6f2zx8dl4w0kzgw3wj8f466mvkcgc3dc-samsung-UnifiedLinuxDriver-4.00.39/opt/share/ppd/ML- /nix/store/nmp023llc8fix567f413a5rqbx4sw45g-cups-progs/share/cups/model/ML- Having diffed them, I notice amongst a huge number of differences: [nawal diff /nix/store/nmp023llc8fix567f413a5rqbx4sw45g-cups-progs/share/cups/model/ML- | grep Version < FileVersion: "2.0.0" < PSVersion: "(3010.000) 0" < QPDL QPDLVersion: "3" < *cupsVersion: 2.2 so raspbian is using a version "2.0.0" and "2.2" of something or other, whereas nixos is using a version "1.2" and "1.1" of similar things. I managed to get my printer to work by copying the ppd across, but I don't understand enough of cups (nor now have the inclination to learn) to figure out what's going on or how to make nixos do the right thing (i.e. in a word, print). I thought this might be useful for someone else who wants to pick it up? Happy to hack around the raspbian if you need more info, or try out things if you need me to while the sd card contains raspbian.
Can you find out what package on Raspbian provides the driver? Have you installed proprietary Samsung driver there? If not, can you try removing ? It seems we have latest version of but not the latest of the proprietary driver but you don't seem to use it.
I'll have a look tomorrow evening - how do i use the new splix without upgrading everything to the same commit?
Find out your current commit with (look at the suffix), then clone nixpkgs repository (), checkout current commit (), fetch my changes () and cherry-pick my patch atop your current commit (). Then you can rebuild nixpkgs with .
I can confirm this works. Thanks for the detailed instructions and for fixing it so quickly! NB: I had to do: (i.e. ) thanks


When the user of the SSH connection used by the SSH substituter does not have a shell configured it defaults to , which causes the following error: Which actually is the decimal representation of the first few letters of the following error reported by (thanks for figuring that out). Since with the release of Nix 2.0 it has become easy to setup a SSH substituter, so I expect that more people might run into this problem. I know of at least another that reported it on the IRC. Instead of the serialized integer error it should just have reported the actual error, or at least it should have given a more specific error about the response being bogus. Forget to set for the user of the SSH substituter connection. system: host os: multi-user?: sandbox: version: (from nixos-unstable around 5 Mar) channels(root): channels(matthijs): nixpkgs: (nixos-17.09 around 22 Feb)
I some debug echo messages to my profile scripts and I got this error as well (with a different number). To fix it, I had to remove any output from the profiles ...
Just stumbled into this too. I figured should be enough on the server part, but alas.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
I'm 90% sure this issue is still valid.
It is.
It is.
I marked this as stale due to inactivity. →
Probably still
Made to show a better error message. But I feel that should print its message to stderr instead of stdout...
I just run into this error running
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


It is an intermittent failure, see , not much we can do about it other than restarting the build. I opened an upstream issue
I've now tried doing a third build locally for this: all have failed. That doesn't seem intermittent to me.
It is succeeding for me most of the time, hydra also managed to build it in the past.
Maybe try setting ? Not sure if it will help but it has helped with some derivations in the past.
managed to reproduce it even with parallel building disabled:
Interestingly lowering parallelism is what seems to trigger the issue for me. If I build with all cores (8) it seems to get past that part of the build all the time, I'm yet to see it succeed when building with a single core.
Can confirm that low parallelism is the problem. is building successfully, which is the first time it has worked for me. That's consistent with what I've seen, not having it build successfully a single time (and it has always only used a single core).
I also got the issue when doing a nixos-rebuild on my 2-core laptop, but it succeeded on the same laptop when using nix-build, which means that all cores are available for just webkitgtk. This is the error message I got:
Would it make sense to add the stopgap fix suggested in So something like this: diff diff --git index .. --- +++ -60,6 +60,12 stdenv.mkDerivation rec { "-DENABLEGTKDOC=OFF" ]; postConfigure = '' # A stopgap for a non-deterministic build failure when using only one core # Upstream bug: ninja JavaScriptCoreForwardingHeaders WTFForwardingHeaders ''; NIXCFLAGS_COMPILE = optionalString stdenv.isDarwin " -lintl";
Open the file Add the following in line 258: add_dependencies(LLIntOffsetsExtractor JavaScriptCoreForwardingHeaders)
This will be no longer neccesary with


Installing Nixos from the 18.03 minimal installation DVD iso, for a fresh 64-bit Hyper-V vm target system, is failing for me at : Running under strace, there is a possible match at but this was from a quick grep from a lot of content, so might well be a red herring. That path is present in the host (CD-booted) system. Full trace . I tried to follow the vanilla NixOS installation instructions as closely as possible. [This is the installation CD system] system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: In case relevant, the hardware- contents are:
Having the same issue right now.
Getting the same using for a fresh installation attempt. Identical installation steps with succeeds.
Confirmed that also succeeds in my case. :heavycheckmark: :x: :x:
I'm having the same issue on an Acer ES1-132
Yep, here too on an XPS 13 9370
I had the same issue. My workaround was to temporarily set after which the install would succeed but not write the boot-listing efivar. Then I manually created that efivar with efibootmgr. I imagine the command would have worked from the installation media, but I'm not sure since I ran it in Debian. (on my system the EFI boot partition is /dev/sdb9) There were also *.efi files generated in efinixos, but I didn't try any since it booted with this.
I saw this as well, on an AsRock Z77 Extreme4. LSLeary's workaround was fine for me since I prefer to boot via rEFInd anyway. I was able to manually touch or cp another boot entry to the destination (per strace) without any error, so it doesn't seem that the firmware is preventing the creation of the variable.
is anyone actively working on this? what does severity blocker signify?
I know this ticket is for a fresh install, but I installed 17.09 and upgrade 18.03 and it worked fine in case anyone needs a workaround.
Also seeing this when installing on vmware, but with custom install media built from the nixos-18.03channel as of today (). No problems with 17.09. EFI is certainly enabled on the host.
I run into the exact same problem while trying to install NixOS 18.03 into VMware.
I got the same behaviour when I tried to install NixOS 18.03 on Dell XPS 13 (9360).
Same issue when tying a fresh install of nixos-minimal-18.03..-x86_64- on VirtualBox. "EFI" option in virtual machine system settings is enabled. I followed the install instructions as closely as possible.
Cannot perform a clean install on Lenovo X1 Yoga 2018.
I got the same issue when installing NixOS-18.03 () on a recent Intel NUC.
A fix has been pushed to the master and 18.03 branches. It will take some time to reach the channel, and for a new ISO to be generated using the fix, but this specific issue should be fixed soon for new installs. In the meantime, should work. Once installed, the option can be put back to the defaults (removed from your configuration) as the issue only affects the installation environment.
For the record, I was unable to boot using the aforelinked efibootmgr workaround on a 2018 Lenovo X1 Yoga. I had a pre-existing Linux boot entry, which I removed, but the new entry that I did not appear as a startup option.
Alternatively,  can be used with grub, This will put the bootloader in the default fallback location. While it is documented as "hardcoded to try first", I'm not sure this is right. It will, though, try to boot that specific location when no other option is possible. As a final alternative, adding at in the ESP (the fallback location) can help; rEFInd will scan for existing EFI programs on the ESP partitions, which would allow selecting systemd-boot. Though, all of this assumes that the installation process finished. EDIT: For anyone reading this in the (hopefully) few hours left until the channel bumps and the iso updates on the website This build is the iso built in the same evaluation that *
Sorry to drag this from the dead but the website has not updated to the new Isos. the build mentioned by samueldr is complete and the iso there solved this issue on hyper-v for me.
Confirmed (what Wolfereign said) - thanks!
I think this issue was automatically closed by the github merge bot, but shouldn't have been.
4 days ago, it shouldn't have been closed; github doesn't know about nixos channels. The current iso image on is made from commit , which is after , and . Simply put, the 18.03 iso do contain the needed fix for this specific issue. The iso image on the website was updated somewhere between ~24h ago (when the channel advanced) and a couple hours ago when I checked whether the iso image changed. I have also, just in case, verified that it does not reproduce the fixed issue. I'm using this post to add this note:
If I look correctly, the ISO on web has been for over thirty hours now, and that commit does contain . I wonder... can you be more specific? What do you mean by "website has not updated"? EDIT: oh, github didn't show me the last posts when I was writing this :-)
The website is updated now. When I checked at the time of my post the isos on the website (official download links) had not been updated.
Edit: Ignore me. We did something silly with efibootmgr to wipe EFI entries during install, which weirdly enough triggers exactly this error.


Enchant 2 (now the default) is long supported by most packages. The following packages need to be updated or removed: [x] gtkspell2 (dead): [x] xiphos: [x] subtitleeditor: [x] xneur: (contains the removal of enchant1) [x] gnome2.gtkhtml (dead): [x] gnome2.gtkhtml4 (dead): [x] gnome.gtkhtml (dead?): [x] php.extensions.enchant:
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 issue is still relevant.
the list from is not up-to-date. e.g. is already fixed maybe we can also close it, because defaults to version 2 and to version 1.
I marked this as stale due to inactivity. →
Updated the list.
Now with xiphos merged You can thick both xiphos and gnome2.gtkhtml4 off the checklist
Pushed the enchant1 removal commit to


Qemu 2.12.0 has released today. We need to update package. Please run and paste the results.


From a recent checkout, where the version of procps is advanced to 3.3.14, happens also for unaltered master. and under nix-shell even weirder with the thing. Just issue the commands above. Doesn't happen with release-18.03, so probably some issue with a more recent autotools version.
Looks good to me. I should have only changed the homepage in the meta tags to begin with. I was of the opinion, it should point somewhere, where one also can report bugs to procps, was a bit too eager then to get rid of sf. : Please take over maintainership for the package.


I am working on a Haskell project that uses . Compiling the project fails with: From my limited understanding of Nix, header files are stored in and is not there.
The default does not include the development headers. Try running from a nix-shell:
Thanks for the response. I tried and then . This resulted in the same error as before. Could you please explain why we'd expect using to work in this case? Is there a simple modification that can be made to the derivation so that it includes the development headers or would creating an entirely new derivation, perhaps named , be a better option?
Ok sorry forgot, that you probably need to do this: Which is working for me at least. Alternatively, you should be able to call stack with the --nix arg. (Sadly it does not work currently with GHCJS):
I have actually gone down the + route. I created a file: and to my file. This resulted in the same error as above. This is why I've gone back now to just using to see if I could get it to work in this more simple setting and then try later on. Just now I tried your suggestion and this also resulted in the same error.
It must be something weird going on with Stack. You definitely shouldn't have to manually install gpgme. Anyway, bindings-gpgme is working for me:
The above worked for me. It finished by printing out . It did also say ; now sure what that means. Any ideas on why this works but doesn't when I just install by itself? I'm guessing somewhere in the Nix machinery it knows depends on and so it installs it in a specialized way? At the moment I'd like to avoid having Nix manage all the haskell packages. My goals is to slowly move the organization I work at towards Nix. I think a good first step would be to provide developers with a reproducible development environment that contains all the non-haskell deps.
I was able to get the integration to work with the following: Turns out what I needed was which is explained in the documentation . I still wish there was a way to get this to work without having to rely on a feature.
That's very weird! We should be doing this for you in buildStackProject: I get this with :
Ok- I might have found the problem. Try this , You need libgpgerror for the gpgme header to work properly. Update: It looks like we are not properly propagating inputs to generic-stack- is not being pulled into despite being necessary for gpgme.h to work (and a propagated input). /cc
I've never looked at . it might be screwed up in arbitrary ways.
Is there any kind of tool to pull in the deps that Nixpkgs would with buildInputs? I think does this but it would be nice to avoid having a script. Something like this: where findAllInputs includes propagated dependencies.
Yeah mutates all these globals cause bash so it's very inconvenient to call more than once. Maybe try dredging up and updating it work as does today :D. This won't be quite the same as there's a few cases of packages hand-modiying the propagated input files .
but a far easier solution is just to loop over in bash (or add an env hook to let the looping be done for you).
Hmm... I guess we will need to put it in shellHook too for it to work with . The problem with the env hook is that gpgme shouldn't have to know Stack exists at all. It might make more sense to just replace NIXLDFLAGS & NIXCFLAGS_COMPILE directly to emulate cc-wrapper behavior (which stack should be calling anyway right?) Has anyone looked into rewriting all headers to give absolute path names for calls? That would solve most of these build cases I think & Nix would treat them like it does dynamic libraries. Probably a huge change but could be worth doing & avoids some of the propagated cases where it really just needs the header file (not all though).
Ahh but can add the env hook, and everything will work out.
That would be really cool! But CPP sadly makes these things quite hard. Because (CPP) identifiers are ambiguous, one would have to bail out on the first unresolved as further name resolution is ambiguous.
I to the and removed the line. This worked. Thank you. However, if I use in place of or if I work outside of a , installing and with , my haskell project does not compile and results in the same error that I initially posted. Is this to be expected? If so, can you please explain why?
Awesome! So when you run it will symlink things into . By default, Nix will set some variables like PATH & MANPATH to pick up things in $, but we don't intend to set up too much besides these "standard" variables. Instead, we prefer to do things inside (which I think is also what uses) that are closer to how Nixpkgs are built. Here is maybe what you wanted to do originally (which still works but gets ugly with lots of dependencies): Hopefully we can fix the issue with propagation though.
Thanks for the explanation. So it seems my idea of using to build a general purpose development environment doesn't really align with what the tool was intended to be used for? And just to confirm, the "issue with propagation" relates only to ?
Is this what you were thinking? I am not able to get the setupHook route to be run correctly in nix-shell so the addEnvHooks doesn't work.


states that it prints out the stripped name to the , but the stores the value in instead. The functionality in the documentation seems more convenient is there a reason not to switch to it?
I've noticed this as well. +1 for changing the implementation to print to stdout.
This one is interesting. There are maybe two dozen uses of that function, but it would be nice to change it. Maybe I’ll look into it tomorrow. Always happy to trigger a mass rebuild. :P
Was fixed in the meantime.


As it stands, the NixOS MPD module runs MPD as a systemd system service. As such it expects that the MPD user account (mpd by default) has control over the audio device. This conflicts with PulseAudio when it's used as a systemd user service (the default configuration). The intent of this change is to extend the MPD module so that it can be configured to run as a systemd user service. The changes remain backwards-compatible so users can continue with a system-wide configuration or go with a per-user config. I have a proof-of-concept of the modified module which I'm currently experimenting with. It can be used in as follows: The result is MPD running within a user slice: [ ] Ability to use a different per user; Probably by providing a option which overrides the other options and simply points to a file in the users home directory (ex. ). [ ] See if it's possible to get realtime scheduling to work. [x] Add NixOS tests. Currently there aren't any. The different options make for numerous potential combinations; I'm to lazy to test all of them manually.
did you ever add support for running mpd as a user service? It looks like just tests in preparation for running it as a user service.
Wow, I forgot all about this. Perhaps because I soon after stopped using MDP. The implementation is still on Github:
An alternative could be to let it talk to pulseaudio over the network. In the past I have used a config in mpd like audio_output { type "pulse" name "pulseaudio" server "127.0.0.1" } and then some config in to allow this access.


MusicBrainz-based metadata collection does not work in . The problem is that the Perl modules cannot be found. Full error message: This should be an easy fix for anyone who knows about Perl in nixpkgs. 1) Install globally (not in ). 2) Make sure includes . 3) Insert a CD. 4) Run .
That dependency seems to be included already. I don't have a CD drive. Is there an other way to reproduce?
I am experiencing this problem too. Even without a CD drive, you should be able to reproduce simply by running . This is an auxiliary program invoked by , a wrapped Perl script that will immediately attempt to import the module in question: and fail as described. I have been able to get partway there by manually prefixing with a PERL5LIB environment variable: That invocation dies with and then presumably I can go find that and add it to the manual PERL5LIB, but now I'm chasing all the dependencies manually. There's no though, right? I don't know how to refer to a Perl that has all required dependencies.
Backported to release-18.09: .
Can confirm that this is working. :+1:
It's broken anyway. I just tried and it install a huge bunch of stuff but ended up with: BFAIST/WebService-MusicBrainz- Has already been unwrapped into directory Configuring B/BF/BFAIST/WebService-MusicBrainz- with Build.PL Created and Creating new 'Build' script for 'WebService-MusicBrainz' version '0.94' BFAIST/WebService-MusicBrainz- /usr/bin/perl Build.PL --installdirs site -- OK Running Build for B/BF/BFAIST/WebService-MusicBrainz- Building WebService-MusicBrainz BFAIST/WebService-MusicBrainz- ./Build -- OK Running Build test t/Artist.t ........ 1/? URL () Request Failed - Code: 410 Error: Gone # Tests were run but no plan was declared and donetesting() was not seen. # Looks like your test exited with 255 just after 3. t/Artist.t ........ Dubious, test returned 255 (wstat , 0xff00) All 3 subtests passed t/Label.t ......... ok t/Release.t ....... 1/? URL () Request Failed - Code: 410 Error: Gone # Tests were run but no plan was declared and donetesting() was not seen. # Looks like your test exited with 255 just after 3. t/Release.t ....... Dubious, test returned 255 (wstat , 0xff00) All 3 subtests passed t/ReleaseGroup.t .. ok t/Track.t ......... ok Test Summary Report t/Artist.t (Wstat: Tests: 3 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output t/Release.t (Wstat: Tests: 3 Failed: 0) Non-zero exit status: 255 Parse errors: No plan found in TAP output Files=5, Tests=15, 7 wallclock secs ( 0.03 usr 0.01 sys + 0.52 cusr 0.07 csys = 0.63 CPU) Result: FAIL Failed 2/5 test programs. 0/15 subtests failed. BFAIST/WebService-MusicBrainz- ./Build test -- NOT OK //hint// to see the cpan-testers results for installing this module, try: reports BFAIST/WebService-MusicBrainz- $ I'm not a Perlie, so I have no idea how to report this or where to fix it.


This configuration: If you poke around in the configuration I linked, you should see that I disable NetworkManager and use a static configuration for my main NIC. I can't think of anything special in my config or with this machine that would affect my usage of Wireguard, but I'm also new to using Wireguard. I'm currently on nixpkgs with a few of my own commits on top of . Please run and paste the results.
It doesn't seem happy when already exists... I have done two things, both of which were necessary, to resolve this: the link manually () sure the path to the private key exists (if not, you get a different failure in the journal, with failing). (It's possible that fixing the private key path and rebooting would have been sufficient). I'm leaving this open for two reasons: user should receive a better error message in both cases. that we're in NixOS, we should assume full control of the interface and just re-configure it, instead of failing in the setup script.
I ran into this issue after trying to debug my wireguard setup. My setup is essentialy identical and I get the same error message. Running the start script that is causing the error results in this output. The offending 2 lines are .
I had to go one step further than deleting the interface. I needed to stop the via then redeploy configuration. But this solved it for me. Nixos should handle this much more gracefully.
I had to remove the routes with etc.
The command is . You can build it in your conf as pre-setup command, but it has the nasty side effect that it possible interferes with other connections.
I am still running into this issue.


Darktable can make use of OpenCL, but the nix package apparently isn't set up properly to allow this. Run : system: host os: multi-user?: sandbox: version: channels(root): channels(lukas): nixpkgs: OpenCL is set up properly on my system: cc darktable maintainers:
I'd been meaning to fix this for myself for awhile. Should be good now, pending review.
Thanks!
Sorry to revive this, but I am still having this problem in dartable 2.4.4 using intel OpenCL Neo driver. Should ti be already solved? Or the fix is still not present in 2.4.4? Thanks
Disregard (at least partially) my last comment. I was using the snap version in Ubuntu 18.10. Using the deb, OpenCl works. Where should I submit the bug for the snap version?


! See the . This is to discuss Darwin-specific issues for ZHF. (or more)


I fail to compile graph-tool on nixos-unstable. The error message is a template one, thus cc
This is caused by
Fixed upstream:
thanks !


Minor cosmetic issue: when using kpcli, the prompt shown to the user says ".kpcli-wrapped:/" instead of the usual "kpcli:/". system: host os: multi-user?: sandbox: version: channels(delroth): channels(root): nixpkgs:
Usually this can be fixed with the --argv0 flag:
kpcli uses wrapProgram which already sets --argv0 correctly AFAICT. Looks like this is a kpcli specific problem:
OK, I understand the reason why --argv0 did not work now. Since this is an interpreted script, we are indeed setting Perl's argv[0] to the right value, but within Perl 0) - Sent to just wrap the script manually and thus control the basename of the wrapped script.
Fixed in


Ulauncher is an application launcher for Linux: Tried to package it myself but I am a rookie and this seems like a bit painful for the first package.
For those interested I made a really quick. However, if you build and execute it you'll realize there's definitely some problems.
More specifically, the first error I run into halts with the following stack trace: Any ideas for workarounds?
If you just examine the result of the derivation you'll notice that things in appear to be in the wrong locations. So that'll definitely make it not work. There's probably something wrong with and I don't think is maintained. So perhaps we can just change the build system if it's easy? Maybe do what  is doing.
Looking at the beginning of the build log, I noticed: Note that it thinks the version is . Maybe this has to do with ? I assume that is supposed to be replaced with something else at But clearly something is not working. That's all I've got. Cheers
Very late edit, I managed to change this after the build via: But last executable still cries:
Would you mind sharing your full nix expression? I can't figure out how to get past the issue. (I suspect you replaced it in ?)
Yes, but I did it after the build. the last status (which is a wreck with too many unnecessary stuff probably, I gave up after trying a bit).
I'm not sure how to implement this in Nix, but we can get past the error by setting the environment variable to the generated site-packages folder (). In other words: We still get an error but I think this is a step forward?
:) I guess. I am still rookie on nixland and this made me confused since we have defined under everything like crazy.
Just so we are on the same page, this is what I am currently using to build ulauncher: I replaced the version substitution code to put the version number where I think the ulauncher source code intends for it to be put. Doing so does not break the build.
The means that the is missing. I'm working on creating a . I've run into , meaning that I needed to make to load a few libraries with using absolute paths. I'm using to apply the patches: Applying the patches is the only way I was able to manage getting to build. The patch was applied with during build time. During runtime, however, the patch was applied, but without substitutions: How do we get the patch substitutions working for runtime?
module is provided by which we already have packaged. definitely should not be used.


I currently cannot execute any 32 bit Linux binaries on my 64 bit system and this breaks updates, since I have 32 bit support enabled in the nix options: I remember that this worked about a week ago, so something has changed. I am new to NixOS, so its possible that I have done something wrong. I used ArchLinux for about 9 years before that and now NixOS for just 3 months and its concepts are still foreign for me. As a long term linux user (about 15 years) I do feel a bit out of place in NixOS. So I am not sure how to fix that myself. Not sure. I have wine installed and support for 32 bit games enabled. Then I normally do just 'nixos-rebuild switch --upgrade' to upgrade, and sometimes 'nix-channel --update'. I also regularly do 'nix-collect-garbage -d'. No idea if that is reproducible or not.
This might be from Could you see if it works without that commit? Also verify that /nix/store/4qj9vzggfzsc34ci79ckaim5cjrwc6ns-bash-4.4-p23/bin/bash executes. I can run it on my system. You can run this to verify that your store is not corrupted:
I solved it now for me. Instead of using the 'linuxPackagestestinghardened' 4.20 linux kernel I switched back to 'linuxPackages419' 4.19.2 kernel and now executing 32 binaries work again. So I guess the hardened kernel does not support executing 32 bit binaries. Does it make sense to have some kind of visible warning here? I normally would not have used the hardened kernel, if that wouldn't have been the only 4.20 version is I get. Its not clear to me when and how those changes in master appear in my nixpkgs/nixos channel (I am on unstable). I would like to use the master branch directly, but I haven't figured out how to best do that yet.
The same here, hardened kernel 4.18.17 and build failed. building '/nix/store/6h9asn7rc93dbwfcs6xaj3k0qgxmg0vh-libtxcdxtn-'... while setting up the build environment: executing '/nix/store/xgf4vra77qrww0n228hd80jsdccdp54w-bash-4.4-p23/bin/bash': Exec format error builder for '/nix/store/6h9asn7rc93dbwfcs6xaj3k0qgxmg0vh-libtxcdxtn-' failed with exit code 1 building '/nix/store/cfwj5yjby2xvagyj69zd1yx8hdhi27ay-'... cannot build derivation '/nix/store/maynq4fxxjc217figygdrgg5q9xnw6yy-mesa-drivers+txc-': 1 dependencies couldn't be built cannot build derivation '/nix/store/wv9b4ayvgnpkvwz81zkk0lm9w4v5pd1y-opengl-drivers-': 1 dependencies couldn't be built cannot build derivation '/nix/store/q61vc27rdbcsrhxifiw89w1qdjax1amh-nixos-system-brix-': 1 dependencies couldn't be built error: build of '/nix/store/q61vc27rdbcsrhxifiw89w1qdjax1amh-nixos-system-brix-' failed Thanks
Maybe the hardened kernel shouldn't set when NixOS' is an ?
It should be 64 bit for the x86_64-linux stdenv. But some packages use the i686 stdenv.
I am not too familiar with stdenv. Is this expected behaviour that a 64-bit system uses 32-bit binaries? This issue is reproducible building as well.
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 should be resolved by - please reopen if there's still a problem.


Here is result of — I'll try to do something about it when I have time but it'll most likely be next year, so please go ahead and fix it if you have time for minor issues.
Screenshot?
pavucontrol has no binary wrapper, thus icons won't show unless relevant icon themes are installed in the system.
Fixed in master.


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


A Go program compiled using nix-shell returns an error when running on a separate server and trying to load a timezone file. file with: $nix-shell $<inside shellgo build $exit $ ./app # name of the app you just created 2019/01/25 20:04:58 All went well: America/NewYork Now copy this file to another computer #./app 2019/01/26 01:01:34 could not load new york locationopen /nix/store/0596k27r6pacyx4jp1bcn8zqyjhji52l-go- no such file or directory The error includes the zip name due to internal reasons the Go team has, but the real problem is that nix replaced with I would be more than happy to send a Pull Request if you agree with the proposed solution of prepending instead of replacing. $ nix-shell -p nix-info --run "nix-info -m" these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked): /nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info copying path '/nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info' from ''... system: host os: multi-user?: sandbox: version: channels(diego): nixpkgs: version is nixos-unstable-2019-01-22 The file replaces the path that the go runtime looks for the timezone information. Original Go code is: But nix changes the first entry, for This works fine if you end up running your go application in the same nix env you compiled it, but when you deploy your go program to a separate server, the path, that can look like isn't present on the separate server and then the lookup fails. is a very common path in Linux distributions. A better way to solve this would be to prepend the nix only path, as the first entry, and then keep and the other entries as they are in the original go source code. The benefits are that those who compile and run in the same nix environment will use the nix path, but those who deploy somewhere else won't have to do any extra work.
I doubt anyone ever considered support for non-Nix and therefore I will mark it also as . I'll leave it open for now as maybe it can be supported (I doubt it).
would you accept a PR with my proposed solution? It won't hurt nix deployments but will help a use case of building a go program in nix but deploying outside of nix.
cross referencing a thread on the mailing list about this ticket/issue so both conversations are linked.
Your explanation and proposed solution seem to be very reasonable to me. I suggest that you submit a PR.


When I run `sudo crontab -e", I get no crontab for root - using an empty one /bin/sh: /usr/bin/vi: No such file or directory crontab: "/usr/bin/vi" exited with status 127 Now I agree that I probably shouldn't do that (I should keep my crontab in ), but a better error message would probably be better. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I also have this issue. Current work around is but this needs to be fixed. See
Please feel free to close as this issue has been fixed.


When used with latest Nix the "new" hash is extracted incorrectly, or thereabouts. This seems to be due to Nix changing the message used to be more friendly to humans: Use an update script invoking common-updater-scripts. Sorry, LMK if repro is needed. Please run and paste the results. I don't expect this to be helpful but happy to provide anyway! system: host os: multi-user?: sandbox: version: channels(will): channels(root): nixpkgs:
It is increasingly messy, perhaps we can drop the old regexes, most people probably set instead of changing nix in overlays so this would not be affected.
What about adding a flag to nix, which turns on machine readable error messages with a guaranty that those messages will not change in a backward incompatible way? Would need someone to add that. But wouldn't that be better to parse error messages intended for human readers with shell tools?
Alternatively, if the build fails, I think we could do something like:
I'm not sure I follow, but FWIW I ran into this and I set and don't set it via overlay. Looks like the new behavior is in 2.2, the current default for : (err formatting might not work for email responses, maybe? sorry :)) I think it's reasonable to drop support for nix older than what's in the tree-- especially since you'd have to overlay to replace it and as you say would likely do via anyway. Oh... that's probably what you meant! :D
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 .
Any updates on this?
I marked this as stale due to inactivity. →
Should have been fixed by
Thanks!


I've just set on my laptop while on holiday. The timezone never updates (tried restarting, waiting a while). Running I see: I see in that the service is run as the user. If I run: I also see the message . Whereas if I run there is no output and the timezone immediately updates (as shown by an immediate change in the time in my status bar, and confirmed by running ). It seems that the user just doesn't have permission to set the timezone. in (and unset ) to see if timezone changes , look for messages with "Failed to set timezone" (will only appear if the timezone it would need to set is different than the current timezone) system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
It worked for me after a reboot. Maybe the polkit rules are not getting appliead during a ?


Using with a doesn't work right anymore after (and the bugfix commit ). I have a simple Docker image I'm using as a , which sets up a user and puts some files in their home directory . (The exact setup doesn't matter.) When I use , the files that are present in the home folder in the base image are lost. This used to work before the commits above. I made this repro derivation: Try running and compare that output to the base image: You will see that the repro image is missing files. CC
(To be clear, it is now broken for a normal , not a layered one.)
Friendly ping , can you tell what broke here?
it seems to be related to the layers ordering. If you both images, you will see layers are reversed. Could you check the associated PR fixes this issue?
Yes, that seems to work! Many thanks :)
Merged so this should be fixed. Thanks !
Oh no, I found another aspect of this which is still broken :(. I think it's still covered under this issue, so I think we should reopen this one rather than file another, is that okay? There's still a problem when you have a command in the command: the layers from the base image aren't present. Here's my repro from above with that addition: If you run and look at the build output, you'll see the output of the command. Because the base image I'm using has an user named "user", you should see a line like this: but due to the regression from you don't see that line. This is preventing me from doing some extra setup that depends on stuff in the base image. Any chance you can see a fix ? :)
Does fix this issue?
Yes , that seems to work! Thanks again


References to (5) should have hyperlinks to the article/section.
These are references to man pages so there can't easily be a hyperlink. I made a PR that makes sure these are referenced to using , though. So that they at least carry some semantic meaning.
My bad I didn't think about the man pages. There are man pages online, too. I found this site: but it'd be nice to have them generated into the NixOS documentation. Having the man page sources piped into HTML would be useful I not a huge space waster.


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


, (nixos-unstable) (nixos-unstable) (nixos-unstable) (nixos-unstable) Scanned versions: nixos-unstable: . May contain false positives.
Fixed in staging (again) via PR


I stumbled upon this package broken while working on , filing an issue to track it. Tested on commit . system: host os: multi-user?: sandbox: version: channels(root): channels(kalbasit): channels(yl): nixpkgs:


, (nixos-19.03) Scanned versions: nixos-19.03: . May contain false positives.


is currently set to just , but I was able to build it fine with on macos (10.14.3) and haven't run into any issues running very basic commands so far.
Would you mind making a pull request?
I don't, but I'm not in the loop and won't be of much use if it's any more involved than changing it to .
So perhaps should be just .


When trying to build llvm-7.0.1 on my armv7 machine, I get the following error during the test phase: Looking around, I see quite a few changes to llvm recently (also the aarch64 failure in ). Ideas? Are these tests expected to fail?
just because I know you know about these things. I know armv7 isn't "really" supported, but this definitely used to work, so... FWIW, I have tried to disable DebugInfo tests, using the method already used to disable other tests, like this: But this didn't do anything. I do not know the test system for llvm though, I just tried to identify which cpp file to remove by grepping around. So maybe this is not even one of the right files, or maybe I disabled it wrong. I have not been able to find how to disable the llvm-dwarfdump tests, also. Hints welcome, if you have any!
I am also able to reproduce these failures. I get the same list of failing tests as what's shown above.
Oh - in case it's not obvious to everybody, I should point out that these are x86-specific tests. Obviously they're supposed to work from any host architecture, but since most developers' machines are x86, I think it's entirely possible that somebody upstream introduced an unintended dependency on the host architecture. I've looked around a bit for any upstream bug report, but so far I haven't found one.
If you're in the situation I was in, and are unable to rebuild your ARMv7 system because it has inexplicably decided it needs llvm 7.0.1 as part of that build when it didn't used to, you can add something along the lines of the following to your You will have to adapt it for whichever package is pulling in the unbuildable LLVM, which you can discover by looking at the list of unbuildable packages that nixos-rebuild spits out at the end and finding the one immediately after LLVM. You can verify that it's the right one by checking all- in the repo and seeing that its callPackage parameters specify llvmPackages_7.
Thanks for the helpful workaround,
Thanks!


migrated from python branch issue tracker
this is not an issue if propagedBuildInputs are used - whether that is good or bad is another thing.
the python rework solved this


migrated from python branch issue tracker
I'm closing this as it seems no longer relevant. From what I could find, python-virtinst is "CLI tools for building virtual machines using libvirt". But it is now merged with virtmanager: <-- contains one single file named MERGEDWITHVIRTMANAGER


I'm using the latest from and it works fine, mostly. I notice the following errors during start-up, though: Looking at the build it seems like all recommended dependencies are there so it doesn't seem likely that those plugins weren't built, no? But why are they missing at run-time? And why are others (like the equalizer) not missing?
After some bisecting I found to be the cause of this, reverting it fixes it. I'm not entirely sure why that is though, investigating..
Was fixed in calf with , which is in the latest version, I have opened a PR to update calf


Installing the gimpPlugins.resynthesizer2 package does not result in a working plugin; the python scripts are installed, but not the two native executables it depends on (called "resynthesizer" and "resynthesizer" Try to install the package "gimpPlugins.resynthesizer2". Expected result: There should be a few new menu options in the Gimp, amongst them "Filter -Enhance -Heal Selection..." Actual result: No new menu options; python scripts cannot find the executables. Possible solution: I made it work by creating a derivation that adds a the following postInstall: postInstall = "installPlugins src/resynthesizer/resynthesizer src/resynthesizer-gui/resynthesizergui"; system: host os: multi-user?: sandbox: version: channels(cable): nixpkgs:
You need to make the plugins available to GIMP, not install it locally. The following should work:
Just tried it (on a nix shell) - but same result; the resulting installation of gimp-with-plugins links to a resynthesizer2 package that lacks the native executables, only has the python scripts (which don't work without the executables)
Hmm, there was an issue with , saves us.


The tests for python27Packages.jinja2 fail and thereby the derivation fails to evaluate. (Full log below) I'm crosscompiling an aarch64 sd image with . I'm crosscompiling aarch64 with nixpkgs .
I had the same issue too, this fixes it for me.
Fixed by


The new option has the example: This is a list of attrsets, but this doesn't match the type, which is Also, it would be nice to have an example config for as well. Besides this, the new declarative configuration options for syncthing have been working well for me. Thanks for including them. CC


So today I tried to build on unstable as described in the . This fails on the dependency . Thanks for your information in that guide! I tried to build according to the guide on and (with slight modifications for compatibility) on they both fail in at this point. Do you have any insights as to how you managed to get it to build? e.g. a nixpkgs commit?
Fix in


When the service starts, the following message is printed to the logs: sshguard[]: sshg-fw-ipset: Could not initialize firewall Blocking does not actually work. Blocked hosts can still initialize ssh connections. Default sshguard config. system: host os: multi-user?: sandbox: version: channels(root): channels(XXXX): nixpkgs:
It seems like that is due to ipsets being created of different types than intended. I'm not sure where it's getting created with that though: # ipset -L Name: sshguard4 Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem Size in memory: 88 References: 1 Number of entries: 0 Members: Name: sshguard6 Type: hash:ip Revision: 4 Header: family inet6 hashsize 1024 maxelem Size in memory: 104 References: 2 Number of entries: 0 Members: Whereas the script intends to create types which is why it returns with an error. I do not see where in the sshguard is type of ipset getting created. I came across though.


is unmaintained, superseded by node2nix and should therefore be removed from nixpkgs Please run and paste the results.
seems LGTM. Wanna open a PR ?


no $ Add to installPhase
For some reason netpbm is installing the symlink to . Will be fixed by


Describe the bug fails on Darwin. To Reproduce Steps to reproduce the behavior: Expected behavior Package builds Additional context Error log: <details<summaryError log</summary</detailsMetadata Please run and paste the result. host os: multi-user?: sandbox: version: channels(yl): nixpkgs: Maintainer information: Possibly related to
On the master branch, I removed the derivation from the nix store with and I built it without substitutes; failed with the same message. This is not caused by , but help me discover it due to the update of the requests python package.
maintainer:
I don't have a way to test on joblib for darwin so this is why I didn't have input on this PR. Is there an easy way to test nixpkgs on darwin? Hackintosh via kvm?
There is that works with some tweaking but I wouldn't describe it as easy. Another option is to ask @ GrahamcOfBorg to do the builds on the PR if there are not too many iterations to do.


Trying to build zathura on unstable, I get: Additional context I can't really see what might have changed recently (I think it started happening about 2 weeks ago....) for it to no longer find synctex. The texlive package is being included as a build input, which should have synctex Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I can build zathura on master and the hydra has been doing ok. Am I missing something?
Hm, I'm not sure. I can't seem to get it to build.... "nix-build -A zathura" on master gives me the same error
This also builds for me on master. Only thing i can think of is your branch isn't up to date.
What do you think could be wrong? My sources are up to date:
I notice that I get a different drv on my system (), I think you may not be building from the master. IIRC when you run it will build from which may not point to your git checkout. If you want to build expressions from the current directory you need to do nix also can download a tarball with expressions, for example like this:
If no path is given nix-build will read and If doesn't exist it will fail. So, command is fine.
I just checked on another x86_64-linux NixOS system that evaluates to on . If the command is correct then there must be an override or an overlay in or that affects the derivation.
Oh my god, you're totally right. I had an overlay in my , which I think I had to add to disable synctex at one point when it wasn't working. Removing that and it builds fine. So sorry for wasting your guys' time but thanks for the help! (Although I wonder why it says it can't find synctex when it should have been disabled with the overlay?) Anyways, I'll close this issue, thanks again, it was driving me crazy!
What was the overlay? There may still be a bug here.
The build indeed fails with . I don't have time to open a PR now but the fix is pretty easy: can you reopen the issue?
Sure - it also fails to build with synctexSupport = false, not sure if your fix addresses that as well?
The option was introduced in I think we should just drop variant


Is it possible to implement mount options for swap partition? This feature could be useful for machines with SSD only drive(s). User could change to options for automatic trimming. of this feature.
I think this is what you want
I still can't figure out solution with documentation pointed out. If I put raises an error. I am using NixOS 14.12 stable. As far as I know swap partition does not have mounting point.
you may do it like this: even though, i didn't test it, but using like this should work regards, iker
Still, it would be nice if there were a more idiomatic way to accomplish that.
Sorry for long pause. After some research, setting discard on swap is NOT good idea. (see ). Setting it, would trigger trim command every time block clears, which leads to poor performance when swap is under pressure. Issue can be closed.
according to the there is a single variant, which is NOT that bad idea:
On top of the case pointed out by of doing a oneshot discard of swap space on startup, there are some situations where there really isn't much of any performance impact. As a simple example, I'm running NixOS in a VM, and the hypervisor translates TRIM/UNMAP/DISCARD commands into calls to fallocate() with the FLPUNCHHOLE flag on the host side. This ends up completing almost instantly due to how my storage stack is set up (and will in most cases where people are using file-backed VM disks), and more importantly, it can be queued on the VM side because it's on an emulated SCSI device. There's literally no measurable performance impact in this case, but there's a big impact on the host side in terms of simplifying space management. Even ignoring use of virtualization, 90% of the performance issue for inline discards in general (not just for swap space) is due to most commodity hardware not being able to queue them, which results in them having about the same impact as an FUA request. Some hardware, however (notably most SCSI and NVMe devices) can queue them, and they have very little impact on performance there.
since this issue got new visits again, i've uploaded , which is a start. I've also looked into unifying and , but it seems a lot of work if such a change doesn't get merged.
What if both and options are in use? /etc/fstab gets 2 entries: Interestingly, the nixos-generate-config options is placed in a lower part of /etc/fstab. There is hope that the first entry gets precedence. But I don't know any mean of checking . the issue still unresolved. Can you reopen, please?
I'm using nixos 21.05 and want to add the "nofail" option for swap devices that are in raid1. Options: can send a PR for a option that gets passed to . I have this and can put it up quickly. This mirrors . can send a PR for a specific option. can use , which can support arbitrary options. But then won't be reproduced correctly. Any opinions?
The approach would get my vote, as it avoids any possibility of arguments between users and developers when a user wants to use an option the developer thinks should not be used (such as the option that started all of this).


Describe the bug When I'm trying to install he arduino or ino package on MacOS I get the error message has wrong length for hash type 'sha256'. , one of the MacOS entries has a hash that is longer than all the other hashes. To Reproduce Steps to reproduce the behavior: Run: Expected behavior Arduino is installed in a nix shell. Screenshots ! Metadata Please run and paste the result. Maintainer information:
In the pull request mentioned above I have corrected the obvious error in the hash. I don't have Nix on Darwin to try it on, can you?


Project description sasquatch is a varation of the unsquashfs utilty that can unpack a much larger amount of vendor specific flavours of squashfs that the regular unsquashfs utility cannot unpack. It is distributed as a patch to the regular squashfs-tools package (so might need some extra work to work with the squashfs-tools package already in nixpkgs). Metadata homepage URL: source URL: license: gpl2+ platforms: linux


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


Describe the bug After installing inkscape either in the user or system profile, no icons are found. When opening dialogs such as "Fill and stroke" or "Layers" the program crashes. I've confirmed this on two of my machines. To Reproduce Steps to reproduce the behavior: inkscape that all icons display incorrectly to Object -Fill and Stroke crash Expected behavior Inkscape should have the full set of icons and dialogs should be accessible. Screenshots ! Additional Context <details<summaryConsole log</summary</detailsMetadata system: host os: multi-user?: sandbox: version: channels(root): channels(riley): nixpkgs:
I think you can easily fix this issue by installing an icon theme to your system.
I believe these icons are part of Inkscape. Possibly issue with gdk-pixbuf loaders – though, I cannot reproduce it within plain xterm session. What desktop environment are you running? Does adding to Inkscape’s help?
Sorry, I should have mentioned - I already tried the following overlay for inkscape after reading the gdk-pixbuf issue and related ones. Unfortunately it didn't seem to change anything after rebuilding and compiling. One of my computers is running sway (launched via startx) and the other i3 + sddm.
Maybe does not work because of :
That worked! I to the overlay and all the icons show up, and dialogs work. I tried looking up docs on but I couldn't find much about it, what does it do exactly?
:confused: I thought the issue with strictDeps only touched gobject-introspection
IIRC, it might also affect hook’s not being picked up correctly. Does the following work with enabled?
Yes, that worked! Would the best workaround for now be to add those inputs to the derivation?


Describe the bug After upgrading to 19.09pre, I am always asked for a password to unlock from . I don't recall this happening in 19.03 Some more info on how to set this up: To Reproduce Steps to reproduce the behavior: KDE with KWallet enabled out and back in to launch chromium that a password is needed Expected behavior Password used for login is used to unlock kwallet. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(mbauer): nixpkgs: Maintainer information:
What display manager are you using?
This is the sddm display manager.
I've also noticed this.
I wasn't upgrading from stable, only from ~a few months ago, so it must have been relatively recent.
The issue here is with the pam module then if it's not automatically unlocked. ~Do you use Plasma 5 which adds?~ (read it says you use KDE) I believe this was broken with lightdm and I've recently fixed it there Could you try using lightdm and see if there's a difference?
Yeah, I think this one is KDE specific. Noticed this in my log: Looking at the coredump gives me this: Looks like a wrapping issue. This is what kwallet looks like:
I'd agree that it's most likely a wrapping issue since that's the only other major change we could tie it too. cc
I agree that the failure in sounds like a wrapping issue. Could you confirm that exists? Unfortunately, I can't tell which platform integration plugin it's trying to load; I would need to see the environment in which PAM loads.
twmn now crashes in QGuiApplicationPrivate::createPlatformIntegration again as well (I remember this happening a long time ago) I remember before I could do but even now that doesn't work
This looks like it's not happening anymore on my system. Probably fixed by either or
Actually still seeing it...
Not sure what's happening so I'll run a git bisect on it.
Should be fixed with .
It works correctly on 19.09, but regressed on current unstable:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Hi, I get this again on 20.09 stable. In my case this happens cause of: Core was generated by `/run/current-system/sw/bin/kwalletd5'. Program terminated with signal SIGSEGV, Segmentation fault. 0x00007fa0556062ec in QObject::disconnect(QObject const, char const, QObject const, char const) () from /nix/store/9fmvcacvkj6s65j3l5pf96nbqwjp73wb-qtbase- /run/current-system/sw/bin/kwalletd5 seems to crash only with Plasma sessions


Project description Oh My Fish provides core infrastructure to allow to install packages which extend or modify the look of fish shell. It's fast, extensible and easy to use. Very similar to Oh-my-zsh that is already in NixOs package repo Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin,
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Any news on this?
I am still trying to understand how oh-my-zsh works.
Well, it just looks like a copy-paste. Just a giant install phase. <details<summaryTREE</summary</details
Isn't this issue about oh-my-fish instead of zsh?
Yes, it is. And I am studying oh-my-zsh in order to use it as a "template".


Describe the bug A clear and concise description of what the bug is. Looks like a new failure for mariadb-server: Currently blocking nixpkgs-unstable
I strongly suspect the update in is the culprit


, (nixos-19.09) (nixos-19.09) (nixos-19.09) (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
Needs patching on master, 19.09, 19.03. CVE-2019-: CVE-2019-: CVE-2019-: CVE-2019-:


Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: -build -A chefdk ./result/bin/chef ./result/bin/knife Expected behavior The chef executable is there but is broken, the knife executable isn't even present. Additional context broke chef, it worked before that commit. I've bisected it down to that changeset. Problem for me is that I don't know ruby or the ruby ecosystem... This is a problem in 19.09 as well. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
cc
I also ran into this; I tried to debug and build it myself locally but it never seemed to rebuild when I ran in my local copy of nixpkgs. Even so, showed just the binary and nothing else. Eventually I tried the following diff to force a new build: Which caused to actually rebuild, and for some reason the rest of the binaries showed up in even with no other changes: I'm relatively new to nix, so not sure why bumping the version changes anything.
Interesting find! Just changing to makes it work as well, even without adding a version to the end of it. I tried keeping and adding a separate attribute but no such luck. There's something odd going on with I'd say.
So what seems to happen is that bundlerEnv is two different things depending if you have a or a . Maybe there's a bug in there somewhere: But I made PR's to revert to using instead for now.
Seems like this is still/again a problem ( missing) on NixOS 21.11 since it has been again mass-replaced in
After initial testing this seems to work. Are there any downsides to using here? (except for the fact that we need to list out executables to be exposed)
I don't know the ruby tooling in nix enough to know if there's any downsides or upsides of making that change. however, I'm not sure why version is removed? If you would make a PR of that we could ask someone with more ruby insights.
Sure, I can do that next week. IIRC / changes behaviour depending on existence of param. If it is missing, it'll be pulled in from relevant gemfiles in anyways.
Sounds good to me, I'm currently running my install from nixos 19.09, because it was the latest release where I found it working :wink: I guess that's the power of Nix, but it's not a good thing to have broken packages like this. So ping me when you have that PR open and I'll test it it and possibly merge it :)
Heyho, any updates on this? :) I finally also migrated my work laptop to NixOS and just ran into this because the binary is missing. I am not at all experienced with neither Nix or NixOS but just renaming to in the appears to fix the problem, the presence of the version variable apparently doesn't have any impact on the result.


Describe the bug See https://nix- The particular cases that fail are I believe rust was updated recently (was that in the release?). It doesn't appear upstream has made a release recently, so perhaps if this report is forwarded to them they can direct us to which patches could fix the test failures etc. cc
According to and bug reports, this seems like a ulimit issue. An interesting workaround for hydra could be using , as suggested in but it's certainly isn't necessary on my machine because I've tested the build and it passed it.
sounds like it would make an already long checkPhase longer :rofl: How about we try ?
We can try this indeed. The question is, what are the default limits of a build user on hydra? Are we sure this might make a difference?
I noticed you've marked sequoia as broken in . Even if a package fails to build on hydra butt doesn't fail locally, does it mean we mark it as broken in its ? Doesn't sound right to me..
That's was the motivation for the issue being opened. If we bump in preCheck and unmark it as broken I think we should be good. ofborg can serve as testing perhaps similar to hydra.
The point is, that we haven't even tried playing with these settings. I would have tried doing it my self but since I know nothing nor I have any effect on Hydra's deployment etc., I wouldn't even know how to test it. What bothers me is the fact it was marked as broken without any attempts by someone with more influence then me to debug it's failure to build only on hydra. Are we even sure this wasn't a failure that happened only once?
Should we close this issue with the PR?
No, it's still failing , at least for hydra, it runs out of file handles
A bit off-topic maybe but I generated a Nix expression for sequoia using , as build times for sequoia where around hours for me. It works now like a charm, as every crate got its own derivation. It can be found here, as a flake: Maybe repackaging with could be an option?
This may be an option, but unpleasant as the generated deps file usually is 1-10k+ of generated noise. (for local building, this works great)
Yeah, that noise is a bummer. Sometimes I dream of having all of packaged the way we do it with , but I guess that would blow up Nixpkgs indefinitely. But maybe someday when Nix flakes are ready? …
I'm not sure I have enough time to have a good view on this. What's most important about specifically, is the fact we use upstream's to install many other files that should be part of the package's output - files such as libraries, ZSH/Bash completion files and headers. So I'm not sure how will this go together with the approach.
If anyone is interested in a sequoia flake which is built incrementally (vs. everything built in a single derivation), I try to maintain one here:
sequoia , but it hasn't tried 0.16.0 yet - .
Yep, we need to fix it for python 38 though


Describe the bug By default and according to bazel documentation (), bazel is looking for a system-wide configuration is . In I decided to override this path and make it point in . It was the easiest solution to pass arguments to bazel in order to fix a few runtime issues. However it breaks the assumption that user can configure bazel using . To Reproduce Use bazel from nixpkgs with . Set some bazel settings in your file Observe that bazel ignores this file Expected behavior I'm opening this bug report to discuss what should be the expected behavior here? Should we respect the ? If yes, I'll open a pull request to restore the previous behavior.
I'll be in favour of keeping support for all paths specified in the documentation - having a system-wide is something people might want to make use of, so we shouldn't take away that possibility. We currently set the following options in bazelrc: We should either patch these as defaults into nixos, or introduce reading from a distro-provided location (should be coordinated with bazel upstream). I think adding a wrapper is a bit too much for all these options.
I do agree with your point of view. I'll try to propose a PR which restore the old behavior. In the meantime, I'm open to other comments on this issue. Regarding the options you quote, they are used in a local during build only. The global bazelrc that I provide is way simpler: Both were ad hoc solution for different problems, respectively issue and commit .


Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):


on Hydra: cc
Since it's been building for me, checked if I was sitting on any changes and while the commit message doesn't indicate that it fixes anything (eep), it does seem to fix this issue: Don't remember enough details to justify it fully offhand (again d'oh for not writing it down at the time hehe) but hopefully this helps work towards a suitable resolution :).
Naturally this breaks in as well.
Yep, broken for me too. Haven't had time to tinker yet.
I have the same problem, but the commit mentioned fixes it for me.
So are we just waiting for this commit to be in the unstable channels?


Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency. The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.


Describe the bug The stable channel was last updated 5 days before. The blocking issue seems to be the build of nlohmannjson timing out. To Reproduce Steps to reproduce the behavior: to local nixpkgs repo: latest changes: stable channel: : That works, so there is no actual issue with the build. The problem is that a test times out on the CI: Maintainer information:


p4merge is unable to start due to missing library. results in:
cc
Fixed by backporting


Describe the bug The latest macvim fails to install with a build error like below I think this change is the cause: The previous version builds fine. To Reproduce the channel to the latest one. or update macvim: or will see the error back to the previous generation: works fine Expected behavior Should install/update fine. Screenshots N/A Additional context macOS 10.14.6 (18G87) Metadata Please run and paste the result. Maintainer information:
cc:
Huh, it builds on my 10.14.6 machine, I wonder what the difference is. Also looking through the build output right now I see on the link command for MacVim. Did you customize macvim, or just build it as-is?
I guess the link command for the binary doesn't include , just the one for .
I don't have any customizations.
Ok I’ll look into adding the right flag to the Vim link step when I can.
Can you test and let me know if that fixes it?
Will do but I'm quite new to nix and don't know how to apply that change to my local nix env. Any pointers?
Normally I'd suggest using to build it, but that builds with the sandbox and macvim can't build with the full sandbox (it requires the sandbox to be off or in ). Given that, what you can do is just check out the PR branch. If you have a git checkout of nixpkgs this can be done with . Then you can run to build macvim from that checkout. If this succeeds it'll create a symlink in the current directory that contains the build results. You could in theory install this into your environment too if you like, with .
Can do or
worked. Thanks, & !
Thank you for testing. I will merge the fix now.


, (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
CVE-2019-: Fixed at version 0.60.8 (nixos-19.09, nixos-20.03, nixos-unstable).


, (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
See also: ,
09 updated in (staging ATM, but should get into channel within days). I trust the bump solves all these CVEs.


Describe the bug git fails to build on darwin Metadata nixpkgs at Maintainer information:
cc
example hydra log: culprit failing tests:


Nixpkgs has 0.11.6, the latest release is 0.11.8


Describe the bug I'm installing send2trash Python lib from the unstable channel. It should be the 1.5.0 version, but it 1.4.2 in fact. To Reproduce Steps to reproduce the behavior: write the following: send2trash buld results: Expected behavior The expected result should be: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Link to the nix package


Project description Cryptomator is an application providing client-side encryption for cloud storage. Metadata homepage URL: source URL: license: GPLv3 platforms: linux, darwin
Source URL:
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
This is still relevant to me. There is currently no way to get transparent encryption on any cloud-drive.
guys, whoever is interested in cryptomator testing/reviewing are welcome: we absolutely need it for darwin platform as well?
Let's first get it merged for linux, we can then base on that and check if we can get darwin working too.


, CVSSv3=9.8 (nixos-19.03, nixos-19.09, nixos-unstable) Scanned versions: nixos-19.03: ; nixos-19.09: ; nixos-unstable: . May contain false positives.
03 is out of support - we don't backport security fixes there anymore.
But this was also about nixos-unstable.
This was a grave mistake from your side. See


Describe the bug I have a NixOS installation with a very simple xserver configuration: When trying to rebuild with master I get an error: To Reproduce Steps to reproduce the behavior: my lines from the above Expected behavior The old configuration should continue to work unless I opt into Metadata Please run and paste the result. Maintainer information: This has to do with cc
Right, looks like there's a bug when constructing the legacy the session name from the legacy defaults. Specifically when only supplying a default for the window manager. Will fix.
IMHO, is only meant for mutable state like database schemata, that does not offer downgrade/rollback path. Abusing it for versioning option tree only adds complexity for little benefit, especially when we already employ other transition aids. Nevertheless, this was an oversight on my part. Something like this might fix it:
What is the proper way to update my configuration to the new system? Where should I look for that information? Are there release notes? I couldn't figure it out from
Yes, release notes are included in the pull request: Also the module system should give you upgrade instruction when we fix the oversight. Could you test the patch above?
Your patch fixes the issue for me.
Closing since this is fixed.
We still need to apply the patch to the nixpkgs.
Oops, thought this was
Yeah, I just looked up that one, but it actually predates me filing the issue and it's currently the latest commit for the file.


Describe the bug I just tried to update my system today. It updated Flexget from 3.0.31 to 3.1.11. Installation went smooth but flexget ultimatively crashes when running. To Reproduce Steps to reproduce the behavior: flexget it it Expected behavior No crash Actual behavior Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(hyper): channels(root): nixpkgs: Maintainer information:


Describe the bug See This is because vmTools.diskImageFuns.debian9i386 doesn't build
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Closing since indicates that it fixed this.


The soundfont that is packaged in is no longer available. The URL in that file is , but that page says: "Sorry, this is a wrong download link.". No packages depend on this package.


On current master (). Fails with See also the . Additional context The hscolour derivation mentioned here does not contain in its . It seems sufficient to make be a propagated build input for , after doing so I can build ghc itself. There's a lot of Metadata Maintainer information:
Can you send a PR fixing this?
Done, see
[ ] port to
Since this issue was opened the situation has changed. There's still no ghc on aarch64, but now it fails due to [the lack of aarch64 support][] in (aka ). [the lack of aarch64 support]:
After PR the default ghc builds for aarch64 (, ATM only in branch).


Describe the bug The recent Haskell generic-builder changes for Darwin (in particular according to bisect) have broken . To Reproduce from a nixpkgs at or later on Darwin. This fails with . Additional context is a pure Haskell package, that depends on , which is what actually uses the C dynamic library. So the problem seems to be that fails to include the C library in its closure. Interestingly, this C library has filename not , even though it looks exactly like a dylib as far as I can tell (I'm not expert in macOS linking): So I can see why would fail to be included into by . However, I don't see why broke it. Nothing to do with the C or Haskell packages involved has changed for months. Updating the generic-builder to include as well as files does fix the problem for me, and seems benign, so I'll submit a PR for that. But I don't feel I understand everything going on here, so I'm opening the issue in case more qualified folks can identify a better root cause fix. Metadata system: host os: multi-user?: sandbox: version: channels(simon): nixpkgs: Maintainer information: Ping from the original changes - thanks for all your efforts!
Just noting here that there is some useful discussion .


Describe the bug I have installed the du-dust package by attribute name (because if I install by name I get the wrong package), but when I run nix-env -u it gets swapped out for an entirely different dust package. To Reproduce Steps to reproduce the behavior: Expected behavior I would expect the du-dust package to be upgraded if a new version is available, no-op otherwise. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(frijters): nixpkgs: Maintainer information: Maybe ?
Thanks!


Describe the bug Attempting to start xpra fails with the following X server log: To Reproduce Steps to reproduce the behavior: run start :200


Describe the bug Tribler does not have any desktop icons, and does not show up in any menus. There is a desktop file in But it's not being included by the desktop environment. Maintainer information:


Describe the bug On a ZFS-enabled 20.03 system: IMHO zed does not need the ability to send email by default. Also mariadb-connector should have a separate -dev output so that its doesn't end up in the system closure.
cc
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Seems still important: And: And:
Adjusted to milestone 21.03. BTW, If someone wants to backport the fix it shouldn't cause any issues.
Took a stab at this in


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


PR broke -- first discovered in Before that PR, the systemd service ran as , so the nginx master process ran as root, and then the worker processes ran as an unprivileged user ( , or by default if thta line is not given). Now the systemd service runs as , including the master process. When you change the default back to root (e.g. because your setup needs the master process to be root, or for replicate the setup as it was in 19.09) using , it does not work out of the box. That is because the module now assumes that nginx will run only as 1 user, and it sets file system permissions that way. But nginx running as root makes nginx drop privileges to or the configured , and the file system permissions are not set up correctly for that as shown in
FYI this is how I'm handling the situation with : The sysadmin should override and to set the master process user and group, while the and options set the effective user and group.
The way the tmpfile rules are currently written is that the group doesn't have write, only read access to . So it doesn't really work well with running the nginx master process as root, and then drop permissions to a regular user. I assume you also don't want to run worker processes as root either :laughing:… I'm not sure how to properly approach this problem. Can you elaborate a bit on what's your usecase as running the master process as root?
are you able to test this configuration out and report back: Please take special consideration to look over your directory (under ) and the permissions there. I'm not familiar on what user/group permissions the process assigns to log files when it runs with as the master process... possibly a minor tweak to the will be required, but let me know what happens with your test. If this works we need to simply add documentation on how to run with as the master process, as I have explained above.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Just from the go/no-go meeting, I approved of changes being backported to 20.03
I've gone ahead and tested the above configuration snippet. I had to make a few tweaks and ended up with this as the required configuration to get to run with as the master process but as the child processes: can you please describe your requirement to run the master process as ? I'm not familiar with so I have a hard time judging whether your case is an edge case or not. depending on the answer from we need to make a decision about whether we need to simply improve documentation, or improve documentation and modify the module code to make this use case better supported. I'm currently leaning toward this being a documentation only thing, but let's wait to hear what has to say.
I think your suggestion is good, I will try it today for our setup and report back. If it works, then I agree that it is sufficient to document your approach in the release notes (and perhaps as a description in one of the config options (probably the one for is best). On my use case, it is: being able to configure nginx the same way it was running on 19.09 for smoother migration, also so that one can upgrade to 20.03 already before fixing all the other things one's nginx uses that may rely on the master running as root
NixOS does not complain when options on non-existent systemd services are set (should it?) -- that took a while to figure out :grin:
I have checked your approach now on my staging deployment; it works (with the typo removed). What we should add to the changelog:
glad to hear. Thanks! :tada:
PR: We should cherry-pick it on after merge.
Thanks for finding the best solution!


Project description An advanced menu editor that provides modern features in a clean, easy-to-use interface. MenuLibre is developed for users who want to manage their menus without ever needing to read the spec or use a text editor. Budgie, Cinnamon, GNOME, KDE (Plasma), LXDE, LXQt, MATE, Pantheon, Unity, and Xfce are all supported. Metadata homepage URL: source URL: license: gpl3 platforms: linux
This project now managed on GitHub: Code: Bugs: Translations: Wiki: Homepage:
There's a module helper function that can generate files. Not as easy to use as menulibre of course, but reproducible.
Thank you. I edited the description for it to be accurate
I marked this as stale due to inactivity. →
Well, it would be good to have a formula for this.
I marked this as stale due to inactivity. →
This would be really useful. I would write a derivation but I'm not confident in my Nix skills to do so.


Project description Code Intelligence for Vala Metadata homepage URL: source URL: license: LGPL2.1 platforms: unix, linux, darwin, ...
any relation to
There are some efforts to merge the two servers but otherwise they are independent.
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .