Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


Describe the bug Installing the latest SBT is not possible. To Reproduce Expected behavior Install is successful Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata


Describe the bug I'm trying to get Steam big picture to work with , xbox wireless adapter and a couple of xbox controllers. But if Steam is already running and I turn on my controllers, they successfully connect to the dongle, but steam doesn't detect them. If i first turn on the controllers, and then i start Steam, it recognizes them and they work fine. xow: I couldn't use the service file provided by the package because it would never start. I read somewhere that systemd is picky with symlinks, so i defined it myself, now it's starting fine. I also had to blacklist else xow would crash. Steam: To Reproduce Steps to reproduce the behavior: sure xow is running fine Steam on steam controllers to see if they work (they dont) Additional context I think xow is working fine. I tried the latest version (0.5) and the last commit, importing udev rules from the package and adding them to I also tried adding my user to the group. It doesn't matter if steam is running in big picture or not, i also tried steam native, still not working. Metadata Edit: Steam won't detect controllers even when using the wire. And also i tested the controllers with and and they work as expected. So i'm pretty sure the issue must be with steam.
This might be an upstream problem with , have you tried using it on a non NixOS system? I also maintain (a kernel driver for Xbox controllers) and I don't have this problem with Steam. Maybe try to test if there's still a problem on your system with xpadneo?
You might also want to try enabling xow using the NixOS module instead of writing a custom service:
Yes, i have another system with Arch and it's working fine there. Steam detects controller connections even when it's already running. That's what i tried at first, but xow wouldn't start, the service was hanging in an state. And I think it might be because when importing the service from the package, nix is creating a symlink to the service and it might cause some issues. Also I did some more tests with xow and controllers are working fine, , , this website https://gamepad- everywhere it works as expected, even Stardew Valley is able to detect them, but not Steam (well unless i restart it with controllers connected, then they are detected and working). It's really weird, I am able to pair them, xpadneo detects them, but they are totally unresponsive, everywhere. I uninstalled xow, and removed the wireless dongle when i tested this. Since xow it's working fine in browser with https://gamepad- and with some games, then udev rules should be fine , right? I would say it's an upstream issue with Steam, but it's working fine on Arch, so there might be some issues with some libs?
The xow NixOS module is fixed now. The problem was that NixOS specifically bypasses the Install section of service files and the module wasn't setting WantedBy for the service explicitly.
I am wih something similar here, I am using the gamepad via USB , before the config all software detected the control, and I was able to play without problems except for steam, which prevented me from using the big picture, after enabling this option I have the same behavior as steam for all applications, if I plug in the control it does not work until the next reboot. Any suggestions on where to debug to understand why this behavior? Dmesg and lsusb look ok.
Having a similar issue, since I'm not using xow or anything but kernel drivers: Steam isn't able to detect a hotplugged Xbox one wired controller. It works perfectly fine if I plug it in before starting Steam. I can also confirm this behavior works on Arch.
that's my situation too
I guess no news on this? :(
i'll take a look, probably something to do with udev rules. i dont have a xbox controller though, only a steam controller
This problem sufficiently annoys me at this point that if there are any instructions I can follow to provide information I'm happy to do so. Thanks for offering to look. I am currently in possession of 2 xbox controllers, several controllers that show up as xbox controllers, and some controllers that don't show up as xbox controllers. I have this issue with all these controllers to the best of my recollection.
the steam udev rules are almost the same as on other distros, though arch does i'll try borrowing a xbox controller. does this happen with only the xbox one or does it happen with 360 too
sadly i can't find a xbox one controller. the udev rules provided by the steam package are the same as on other distros, maybe it has something to do with our other udev rules. may also have something to do with bubblewrap
It seems to be related to linux usernamespaces which to my understanding remaps the id of the sender of udev events (from 0 to a big number) leading udev to ignore these messages if it's not zero. Running directly on my system and under (running as root and as a normal user) led me to believe this (). This issue may need to be fixed with bubblewrap, I don't think something can be done here. Unfortunately I don't have a solution :sweatsmile: PS : I don't know if fixing this issue will make everything work, .
these look related
I merged someone who has this issue please look into using the patched systemd with the steam fhsenv
I've just tested on latest NixOS unstable. A hotplugged Xbox One controller was successfully detected by Steam Big Picture. Thank you!
i haven't done anything that would have fixed this
Well that is exceptionally weird! Because it's definitely working for me, looks like an unrelated PR fixed it? This is straight out of my terminal, after starting Steam with no controller, disconnecting and connecting again:
This must be a change to how steam recognizes controllers. The program from still does not show events when started within There is still something odd: My joystick Logitech X52 HOTAS is recognized as a gamepad, while when I run steam packages on flatpak, it works properly. I don't know what they do differently in the flatpak version to get it working. Maybe using libgudev or a flatpak specific version of udev in the runtime packages? I have tested adding patched systemd to the fhs of steam, but this did not change anything (maybe some other udev library version was shadowing it)
I marked this as stale due to inactivity. →
I still have this issue, with both an xbox 360 controller with the wireless adapter as well with an 8Bitdo SN30+ in both wired and wireless mode. Starting steam with any of these already connected works, but if one gets connected after starting steam (or worse - shortly disconnects while playing) it will not be reconnected until a Steam restart. However, with a Steam Controller hotplugging works just fine! This happens with Steam Big Picture mode (and also in games, but I guess Big Picture mode is more readily reproducable). I assume I am doing something wrong as others have it fixed, is this really no longer an issue for others? Happy for any pointers and to assist in debugging. (my config is at in case it is needed, i am currently on )
I assume I am doing something wrong as others have it fixed, is this really no longer an issue for others? I have the same issue, with PS5 DualSense controllers. I debugged a bit during the christmas holiday, based on some info in either this issue or some other... By applying a patch (linked from the issue) I was able to see udev starting to detect hotplugging the controller in the Steam FHS env (it didn't detect these events by default), but still Steam wouldn't pick up the hotplugged controller.
I found my experimental config snippet from back then: AFAIR, I was worried that steam itself didn't use the patched libudev, but I'm pretty sure I looked up the process map and found it had (only) loaded the patched libudev, so I'm not sure what's going on. Didn't look at it since.
If anyone just wants to throw money at this problem I highly suggest the to solve it. The real win with this gamepad is that it always shows up as connected to your PC, even when it is powered off. It achieves this by coming with a usb dongle that shows up effectively as a wired joystick regardless if the gamepad is being used or not. Perfect solution for this problem... I have 3. I'll mention a potential con, though: Make sure you have good line of sight between the usb dongle and the gamepad (don't worry, it comes with a ~1m usb extension cable to allow good line of sight) and aren't too far away (3-4 m I would guess) or else the signal is really spotty. In my last setup I used this through the wall and it absolutely wouldn't work for any serious gaming, but now I have the pc in the same room as the gamepads with direct line of sight and it is perfect. But yeah... a real solution would be better and still appreciated by me. Just thought I'd post this in case anyone could benefit from it. :man_shrugging:
Another alternative is to use : in the config: then install and run it: I didn't have any issues since doing it since flatpak was updated to = 1.12
I still have this issue on Nix's version of steam using nixos-unstable. Enabling xpadneo did not fix it either.
may have fixed this
Seems like didn't fix it. I see that it is in nixos-unstable and it seems like Steam still displays the same issue with my DualSense controller. I need to restart Steam before it detects it
I am having this issue on every controller I have: Steam Controller Nintendo Switch Pro Controller PS3 Controller Gulikit King Kong Pro 2 Controller in all 4 modes (Switch, XInput, DInput, Android/iOS) USB adapters for NES, SNES, and Gamecube controllers It occurs when using both Bluetooth and USB, so I am 90% certain it has nothing to do with which controller you are using. The behavior is the same for all of them; when I connect any USB/Bluetooth controller it is not recognized or noticed by Steam if it is already running, but only when Steam is starting up while the controller is currently plugged in. Here's some information on what happens when I use the Gulikit controller (XInput mode via bluetooth): Controller connected and Steam is not started At this point, and are now created Now I start Steam And reports: And now and are created (???) Disconnected the controller with Steam running Nothing new in I reconnect the controller with Steam running* And and is back TL;DR - So it looks like Steam will normally start up and find the controller and then it will create the virtual input devices and . However, it won't create these devices when they are connected after Steam is already running. The question I have is why this happens and what can be done to fix it. It looks to be a NixOS specific issue as the problem doesn't appear to be on other Linux distributions like Arch (just reading off of what's in this thread, I haven't tried myself). If anyone wants me to try anything and test it on a fair variety of USB/Bluetooth controllers please let me know. I think something might be wrong with how the FHS wrapper () seems to be binding the devices that prevents new devices from being seen. EDIT: I just confirmed the and device files are appearing and disappearing in the environment that Steam runs in, so the FHS is actually properly creating those devices. The only difference I can see is that they are owned by in the FHS environment (versus in the normal environment). I can still properly access both. I did see : However, that would imply this is not NixOS specific and instead is default Steam behavior. No indication of how to change that default behavior though, so I can't find a way to confirm it.
This seems related:
Just as an datapoint: The Steam Controller is actually one that does not exhibit this issue for me, at least not when wirelessly connected with the Dongle that came with it. If I connect it via cable then it is the same as usual, only recognized when restarting steam. Also if connected via dongle and I replug the dongle, the controller only gets recognized when restarting steam. But if the dongle stays put and I shutdown the controller (by holding the Steam button for a few seconds) and start it again it works just fine with steam running. I guess it might be similar to the controller described in
I was surprised as well, and a little bit of digging reveals that SDL2 being inside flatpak and disables the unreliable udev-based discovery. And disabling it manually ! I opened to fix this.
Can confirm that it fixed the issue for me. Good job in discovering this
This is resolved for me now as well. Thank you all! :heart:


In a NixOS 20.09 guest on a VMWare Windows host, with dwm as my window manager, the mouse cursor neither moves nor registers clicks when . To Reproduce Steps to reproduce the behavior: NixOS 20.09 in VMWare Workstation Player 16 VM (from the minimal ISO) xserver and dwm and in as normal user with a minimal can you have a look?
I can reproduce this. It does work if you login as but fails if you log into a normal user account. It also fails in .
Oh boy, even in the grown-up DM. That's bad.
Did this fix the issue for you? ? I'm having issues my self. I also posted in reddit to see if maybe I didn't do something correctly.
try the PR I just linked. My mouse problems went away when I compiled the kernel with CONFIGPS2VMMOUSE.
Thank you it works! This will be great to have. This might be a silly question, but is open-vm-tools 11.3.0 required for this to work? I didn't have time to try 11.2.5 on the stable channel. For anyone reading this the name value is MOUSEPS2VMMOUSE, might save you one failed kernel build before you figure it out. Here's my nix config that I used to allow non-root user to use the mouse in Xorg running on vmware fushion on MacOS - This config was a "get it to work" attempt with no regard to what the ramifications of how I went about it. My next step is to figure out what it all really means and see if I went about it correctly.


Describe the bug from should have fledgling Ozone/wayland support. Users on other distros are having success. However, I am not. Looks like it might be a Nix-y thing: and no window opens.
I had it working once: (didn't re-test lately tho) It might also be a hardware/driver thing (changing might also help if it's related to any local state). Do you get any additional output (I usually get way more output)? Or it might be due to one of the many upstream bugs (). But if this is indeed related to Nix investigating/fixing it would be very nice.
too, saw it working once. , local state does affect it. I was having a totally different crash until I deleted . used to get more output, but no, that's everything, verbatim what I get from launching yesterday. It very well could just be upstream, but I'm getting jealous of adhoc reports of those builds working on other distros. Unfortunately I don't have a lot of time/ideas.
Ok, strange. I just tried this again with 87.0.4280.66 and got the following output (in my case this looks as with previous versions that crashed though). <details<summaryConsole output (the 2nd time no browser window appeared anymore)</summary<pre[nix-shell:~/google-chrome]$ which google-chrome-stable /nix/store/j3v003nw7mkhdzys4wih1zvw2lsvm8cq-google-chrome-87.0.4280.66/bin/google-chrome-stable [nix-shell:~/google-chrome]$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGL failed with error EGLNOTINITIALIZED, trying next display type [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGLES failed with error EGLNOTINITIALIZED [(20)] GLSurfaceEGL::InitializeOneOff failed. [(150)] Exiting GPU process due to errors during initialization [(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(374)] InitializeSandbox() called with multiple threads in process gpu-process. [nix-shell:~/google-chrome]$ google-chrome-stable --enable-features=UseOzonePlatform --ozone-platform=wayland [(621)] Failed to call method: org.freedesktop.DBus.Properties.Get: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(621)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: objectpath= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGL failed with error EGLNOTINITIALIZED, trying next display type [(43)] (initialize): ANGLE Display::initialize error : Could not open the default X display. [(773)] EGL Driver message (Critical) eglInitialize: Could not open the default X display. [(1322)] eglInitialize OpenGLES failed with error EGLNOTINITIALIZED [(20)] GLSurfaceEGL::InitializeOneOff failed. [(150)] Exiting GPU process due to errors during initialization [(374)] InitializeSandbox() called with multiple threads in process gpu-process. [(122)] ContextResult::kTransientFailure: Failed to send GpuChannelMsgCreateCommandBuffer. </pre</detailsYou're right, I just tried the exact same version but with instead of and it works pretty flawlessly (videos don't play but the rest seems fine). So this issue only seems to affect Google Chrome. Also: With Chromium I don't get any of those error messages on the console that I get with Google Chrome (only the usual ones as in your initial post, not the ones related to ANGLE/EGL/X11).
Since we will lose some Google account related stuff in chromium quite soon[1], I am looking into using Chrome for some stuff. At the moment I am using Chromium via and it is wonderfully fast and smooth (sway, nixos-unstable, intel-gpu), even though I have to disable something about video acceleration[2]. None of the three Chrome builds start with as reported in this Github issue. When also adding it runs (as a Wayland window), but the performance is bad. [1] ,-By%20Joey%20Sneddon&text=Users%20of%20the%20Chromium%20web,builds%20from%20March%2015%2C%. [2]
could you also report your Wayland compositor and GPU? Maybe that's related. I did test this on Sway and Weston (IIRC) with an old AMD Radeon HD 6950 GPU (Mesa's Radeon R600 Gallium3D Driver). I've also started following a few upstream issues that could be related: (seems Nvidia specific though) (reproducible on wlroots-based compositors) I'm still not sure if this is an upstream issue, GPU driver or Wayland compositor related issue, or Nixpkgs specific (either due to our Chromium packaging, due to some specific system dependencies, or due to issues with our Nix store paths). if you want you could also try to investigate this with e.g. (IIRC I briefly had a look but it's not a priority for me since I don't use Google Chrome).
I am on sway/wlroots/intel-gpu. I'll look into strace, but I fear my Linux debugging skills are a bit rusty.
I am not able interpret the output in any meaningful way, but I was able to get some more log output: conincides with
Wayland works on latest unstable chrome, but rendering falls back to software. Log Messages
It stopped showing window once I close and re-run chrome, but after removing it starts working again.
Current output, just for the record (GPU driver: , flags: ). Current output of (only works via ): Note: This obviously shouldn't try to open the X display. Current output of (doesn't work at all):
I have it working on stable 91.0.4472.114 with just the ozone platform flags, but there's no hardware acceleration at all.
that might be equivalent to the case then (which also works reliably but without hardware acceleration). For M92+ the situation is currently even worse as the GPU acceleration seems to be broken. I need to use to even launch Chromium or Google Chrome (unfortunately I lack time for a proper investigation but at least there are already some upstream bug reports).
With Google Chrome M92+ the Ozone/Wayland support seems to be completely broken on NixOS (coredump during startup): Chromium is still fine though. I've opened since there's also a nasty GPU acceleration regression now.


Describe the bug
There is a version update available
Proposal to increase build timeout
That update PR includes a workaround (using older rust).
Keeping this open until the channel progresses.
updated to .
Could setting help?
we now have an actual failure on master cc
Related
fixes the build of thunderbird.
Channel advanced.


Describe the bug version 1.18.0 fails to build. To Reproduce Steps to reproduce the behavior: Expected behavior Build properly completes. Logs Full build log: Additional context This is blocking rebuilds. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(anna): nixpkgs: Maintainer information:
I'm experiencing this as well.
might be due to spansp upgrade in


Describe the bug It appears that the binary is not included in the output of the derivation. To Reproduce Steps to reproduce the behavior: in NixOS 20.09. a video, e.g. by adding a solid color with “Open Other” → “Color” & dragging it to the timeline. to export with default settings. Expected behavior Video is exported successfully. Actual behavior Export fails with the following log message: Workaround separately. file after failed export. to create the exported video. Notify maintainers Metadata Maintainer information:
Thanks for your report, you are right, export is broken. But was also not included in $out/bin in older versions, so I guess there is a path to mlt missing somewhere, so shotcut does not find melt. We have to find out where.
found it, was changed to , just preparing a PR
I have to apologize for not testing the export after updating to shotcut-20.10.31
Thanks, !


This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
Hi Opened PR for this.


This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
I will also work on this


Describe the bug Suspend to disk / hibernation in combination with ZFS may lead to filesystem corruption. To Reproduce The problem only shows up occasionally about once on every 30 startups. I had been using suspend to disk on my laptop without problem for several years. After changing from BTRFS to ZFS the import of the ZFS pool occasionally stalls when resuming from hibernate. A message says that the pool is corrupted and gets reconstructed. Once the pool was corrupted irreparably. Root cause ZFS does not support filesystem freeze and thaw under Linux at the moment. (see ) The problem is that when resuming from hibernation the initrd tries to import the pool (it also tries to fix a corrupted pool and effectively modifies the pool/partition). This happens before checks for a possible resume from hibernation and before the system returns to the state in which it had been suspended. Expected behavior It may be possible to fix the problem by reordering the sequence of actions in initrd. Unless there is a fix for this NixOS should disable the combination of ZFS and hibernation. (More precisely, initrd should either contain the setup scripts for ZFS or the scripts for return-from-hibernate). At least there should be a warning.
BTRFS is native to Linux, so its suspension mechanism and Linux's were (presumably) always set up to work with each other. On the other hand, ZFS's suspension code has not yet been hooked up to Linux's properly: I agree that— One potential problem seems to be that there seem to be multiple packages that can cause suspension. In my NixOS configuration, I tell and not to suspend, but I don't know whether that's everything that might cause suspension.
Thanks for adding the link. I've a corresponding line of warning here:
Do you suspend to disk with a zvol swap? Because I'm running with root on ZFS on my laptop and I have never encountered problems with suspend to disk, but I'm also using a separate regular swap partition.
I for one use a regular swap partition. I recall hearing that swap-on-ZVOL is dangerous independently of hibernation.
I marked this as stale due to inactivity. →
Would it make sense to automatically add in cases where zfs is in use?
This. A note in wiki or manual will be good too. EDIT: Done ().
I marked this as stale due to inactivity. →
Let's see if we can close this with
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Describe the bug is missing a menu entry to launch the application. To Reproduce Steps to reproduce the behavior: Expected behavior There should be a menu entry to launch the application. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata
see (probably shouldn't have been closed)


With the update to 1.48, rustc is missing some host platform libraries when built as a cross-compiler. Most notably, is missing which causes cross-compiled packages with scripts to fail with the following error: The native (host == target) compiler is not affected. The diff between the native and cross directory is as follows: This seems like an upstream regression. Interestingly, the list of missing libraries exactly matches the list of libraries installed in . cc
looks kind of suspicious.
Or actually looks like it would explain the issue. I think we need to add the host platform to targets as well.
That makes sense to me and sounds like a good solution.


Describe the bug on a NixOS configuration with systemd-boot as bootloader (the default for NixOS installs on UEFI systems) fails with this error: I checked that the file exists, so what's missing in the kernel since it reports "No such device"? Steps to reproduce This happens with nixos-20.09 and nixos-unstable, but not nixos-20.03. (Just change the command above.) Expected behavior The build succeeds, like it did before (on nixos-20.03). Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:
Disabling ~systemd-boot~ efi settings from results in So the insmod error is the same, but now the init script doesn't die on
Ah, the default value of is , and with that value it actually succeeds. So it's not really the systemd-boot part of the config that is broken.
Oh, this comment recommends NOT to set , because it can wear out the NVRAM:
Ah, the default value of is false, [...] Well, except that sets it to true, so it is enabled by default for NixOS EFI installs.
Interestingly, the uses . That results in success!
Now the question is, where to set (or )? I see at least these places where conditionally adding it could make sense: Call site: Option declaration, in qemu- Implementation, in qemu- In the systemd- module:


current version: unstable-2017-10-06 desired version: 0.2.0 maintainers:
An option in the service definition to overwrite the package would be nice, too! :smile:
Why is this needed? -options are usually implemented if modifying the package in question with an overlay is a bad idea because it would mean that a lot of leaf-packages would require a rebuild as well. An example for that would be .
Ah, okay.
could you please update this package?
Oh sure, thank you for the ping :)


Describe the bug Firefox crashed because my disk was full. I wanted to submit a crash report, but the site the documentation mentions don't exist. To Reproduce Steps to reproduce the behavior: in firefox Expected behavior firefox works like an official release Screenshots ! Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Firefox is compiled without crash reporting support by default: I don't know why, though.
Probably because it could be considered tracking. But i think it's optional to actually send the crash reports and they don't contain personal data and are very useful to fix crashes. We would need clear guidelines which kind of tracking is OK.
I don't have time to open a discussion about that. Since it crashed again, i tried with a workaround: rebuild fails with this error. i guess it's due to the structure of the firefox packaging. the option is in the while the package is defined in any idea?
Looking at the definition quickly, I'd try
The build starts with that, but fails exactly at the crashreporter. I guess no one has tested that in a while. It took 33 minutes to get to that point with a i9 cpu (16x 4GHz). 32 GB RAM would be good, 16 will SWAP.
I got it to build, on a second attempt Anyway, I don't think it will be that easy to actually use the reporter. For example, I don't think our default build keeps debugging symbols, and I don't expect it can really report anything useful without them.
I marked this as stale due to inactivity. →
I just built with crash-reporting enabled and everything seems to be working perfectly. Is there any reason we can't turn this on. In my case the reports are not even sending without asking first. If tracking is a concern may we can change the default from to .
Since I don't hear any clear objections I have opened to hopefully push this issue along.


Describe the bug The Emacs packages for don't successfully load. To Reproduce Run a from the following : After opening Emacs from inside the and running , we get the following: Expected behavior The packages should be properly loaded, and they should offer syntax-highlighting for select languages. Notify maintainers No one has any particular responsibility for this package. But might be interested in this. Metadata Please run and paste the result.
I'm currently using this, but it stills need some work. Languages grammar are downloaded instead of being built (each language should have it's own separate nix package), and I'm not happy about the but if the grammar bins are in directory will put them in the .
I marked this as stale due to inactivity. →
Unstale
facing the same issue
Same. What's going on with this issue?
So, I've been looking into this a bit and kind of understand what should be done, but haven't been able to create enough code for a working PR yet. So, basically what you want is to build a rust package from here: The result of the build is and this needs to be built as a dependency for so the file is available for it as . I think it should be enough to link whatever file gets compiled from to the if I read the code correctly. Then, the next is to link all the compiled tree-sitter grammars for the emacs package to find, something copied from how the neovim plugin does this: I'm not completely sure where to build all these packages and I'm running out of my personal time to get this working together. What I see in the current state is many packages linking as a dependency, but is just building the emacs package, not using to build whatever is in the directory and linking the resulting library for the lisp libraries. And the grammars are already in the nixpkgs, you just need to link them to a place where the emacs tree-sitter plugin can find them.
Hey all. I'm still working on fixing this due to me needing tree-sitter for my emacs setup and wanting to understand nix more. Here's the work so far: It now compiles the rust module correctly, and uses the linking strategy from for the languages. It still tries to download files from github, so I either don't link the files to the correct location, or I should patch a method to prevent the download process. I think the best solution would be to use the grammars already available in the monorepo the same way as does. My first try with them was with , but some of them won't work together with the emacs library due to licensing issues. And I also got myself to the download problem, but I think this is not due to files not being the pre-compiled ones from github, but again about some linking issues. If somebody wants to try this out and give me feedback, I'm all ears. I will probably spend some Christmas holiday spare time to make the PR happen. It is very close already.
I made a PR and now it works at least on my NixOS laptop. It would still be nice if we could either utilize the grammars already available in nix, or at least we'd be able to compile them in the derivation instead of just downloading the binaries. I'd be happy if you could try this out and see if it works for you.


Describe the bug gpgme fails to build on macOS To Reproduce <details<summary<codenix-build . -A gpgme</code(<iexpand to see the output</i)</summary<prewarning: Nix search path entry '/nix/var/nix/profiles/per-user/root/channels' does not exist, ignoring this derivation will be built: /nix/store/zwf2jgy24qs7b69n1rb5pg9ywwmi82f0-gpgme- building '/nix/store/zwf2jgy24qs7b69n1rb5pg9ywwmi82f0-gpgme-'... unpacking sources unpacking source archive /nix/store/sq6ypkha64hcskq8qqw8rv40d9k4y94f-gpgme- source root is gpgme-1.15.0 setting SOURCEDATEEPOCH to timestamp of file gpgme- patching sources applying patch /nix/store/d5svj9vzmvfvlfh67chy0yliwjk50wb5- patching file src/engine-gpg.c Hunk succeeded at 2989 (offset 28 lines). applying patch /nix/store/v28z94l2z3669df0vzwgsi4y53rvv5rc-0001-Fix-python-tests-on-non- patching file patching file applying patch /nix/store/k3dx8r5bp3pqd4dzrydj4yywg6c9p6ja-disable-python- patching file autoreconfPhase autoreconf: export WARNINGS= autoreconf: Entering directory '.' autoreconf: not using Gettext autoreconf: running: aclocal --force -I m4 autoreconf: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in ACCONFIGAUXDIR, 'build-aux'. libtoolize: copying file 'build-' libtoolize: putting macros in ACCONFIGMACRODIRS, 'm4'. libtoolize: copying file 'm4/libtool.m4' libtoolize: copying file 'm4/ltoptions.m4' libtoolize: copying file 'm4/ltsugar.m4' libtoolize: copying file 'm4/ltversion.m4' libtoolize: copying file 'm4/lt~obsolete.m4' autoreconf: not using Intltool autoreconf: not using Gtkdoc autoreconf: running: aclocal --force -I m4 autoreconf: running: /nix/store/ymq2bmizcmzffq8qwi11lpm2sfl0d9r2-autoconf-2.70/bin/autoconf --force warning: The macro ACCONFIGHEADER' is obsolete. You should run autoupdate. ./lib/autoconf/status.m4:719: ACCONFIGHEADER is expanded from... the top level warning: The macroACGNUSOURCE' is obsolete. You should run autoupdate. ./lib/autoconf/specific.m4:312: ACGNUSOURCE is expanded from... the top level warning: The macro ACTRYRUN' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:2996: ACTRYRUN is expanded from... m4/glib-2.0.m4:8: AMPATHGLIB20 is expanded from... the top level warning: The macroACTRYLINK' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:2919: ACTRYLINK is expanded from... m4/glib-2.0.m4:8: AMPATHGLIB20 is expanded from... the top level warning: The macro ACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... the top level warning: The macroACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... the top level warning: The macro ACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... the top level warning: The macroACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... the top level warning: The macro ACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... the top level warning: The macroACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... the top level warning: The macro ACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... the top level warning: The macroACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... the top level warning: The macro ACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... m4/gpg-error.m4:27: AMPATHGPGERROR is expanded from... the top level warning: The macroACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... m4/libassuan.m4:17: AMPATHLIBASSUANCOMMON is expanded from... m4/libassuan.m4:158: AMPATHLIBASSUAN is expanded from... the top level warning: The macro ACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... the top level warning: The macroACHELPSTRING' is obsolete. You should run autoupdate. ./lib/autoconf/general.m4:203: ACHELPSTRING is expanded from... the top level autoreconf: running: /nix/store/ymq2bmizcmzffq8qwi11lpm2sfl0d9r2-autoconf-2.70/bin/autoheader --force autoreconf: running: automake --add-missing --copy --force-missing installing 'build-aux/compile' installing 'build-aux/missing' installing 'build-aux/depcomp' autoreconf: 'build-' is updated autoreconf: 'build-' is updated autoreconf: Leaving directory '.' configuring fixing libtool script ./build- configure flags: --disable-static --disable-dependency-tracking --prefix=/nix/store/9357hqrwqm6wnvl6qnp1hw2h045nw2rf-gpgme-1.15.0 --bindir=/nix/store/r9355cgd5y62qh03h68b4a6lj3w3kcap-gpgme-1.15.0-dev/bin --sbindir=/nix/store/r9355cgd5y62qh03h68b4a6lj3w3kcap-gpgme-1.15.0-dev/sbin --includedir=/nix/store/r9355cgd5y62qh03h68b4a6lj3w3kcap-gpgme-1.15.0-dev/include --oldincludedir=/nix/store/r9355cgd5y62qh03h68b4a6lj3w3kcap-gpgme-1.15.0-dev/include --mandir=/nix/store/r9355cgd5y62qh03h68b4a6lj3w3kcap-gpgme-1.15.0-dev/share/man --infodir=/nix/store/a7im3pbpc9aa0v37wlclqnas2j5cx5kv-gpgme-1.15.0-info/share/info --docdir=/nix/store/9357hqrwqm6wnvl6qnp1hw2h045nw2rf-gpgme-1.15.0/share/doc/gpgme --libdir=/nix/store/9357hqrwqm6wnvl6qnp1hw2h045nw2rf-gpgme-1.15.0/lib --libexecdir=/nix/store/9357hqrwqm6wnvl6qnp1hw2h045nw2rf-gpgme-1.15.0/libexec --localedir=/nix/store/9357hqrwqm6wnvl6qnp1hw2h045nw2rf-gpgme-1.15.0/share/locale --enable-fixed-path=/nix/store/x5v8m4xf9sf07675db7cfi19g9qjp4y1-gnupg-2.2.24/bin --with-libgpg-error-prefix=/nix/store/4sdr1n9fvhpry7410jfyd87sdsvh5422-libgpg-error-1.38-dev --with-libassuan-prefix=/nix/store/c0pfl1d4dw61i3mwzc52akb9vbx223vf-libassuan-2.5.4-dev --disable-gpg-test checking for a BSD-compatible install... /nix/store/5m4875pw1zcd588n7a6j88vwsilvnm7j-coreutils-8.32/bin/install -c checking whether build environment is sane... yes checking for a race-free mkdir -p... /nix/store/5m4875pw1zcd588n7a6j88vwsilvnm7j-coreutils-8.32/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... x8664-apple-darwin20.2.0 checking host system type... x8664-apple-darwin20.2.0 checking whether make supports nested variables... (cached) yes checking whether make supports the include directive... yes (GNU style) checking for gcc... clang checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether the compiler supports GNU C... yes checking whether clang accepts -g... yes checking for clang option to enable C11 features... none needed checking whether clang understands -c and -o together... yes checking dependency style of clang... none checking for stdio.h... yes checking for stdlib.h... yes checking for string.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for strings.h... yes checking for sys/stat.h... yes checking for sys/types.h... yes checking for unistd.h... yes checking for wchar.h... yes checking for minix/config.h... no checking for locale.h... yes checking for sys/select.h... yes checking for sys/uio.h... yes checking for argp.h... no checking for sys/time.h... yes checking whether it is safe to define EXTENSIONS... yes checking whether XOPENSOURCE should be defined... no checking for gcc... (cached) clang checking whether the compiler supports GNU C... (cached) yes checking whether clang accepts -g... (cached) yes checking for clang option to enable C11 features... (cached) none needed checking whether clang understands -c and -o together... (cached) yes checking dependency style of clang... (cached) none checking how to run the C preprocessor... clang -E checking whether the compiler supports GNU C++... yes checking whether clang++ accepts -g... yes checking for clang++ option to enable C++11 features... none needed checking dependency style of clang++... none checking for gitlog-to-changelog... no checking for cc for build... clang checking how to print strings... printf checking for a sed that does not truncate output... /nix/store/n0zyx5b5s1grq0jrcy2xvf7apvh25wry-gnused-4.8/bin/sed checking for grep that handles long lines and -e... /nix/store/pmbv3czhsa816msq51ngb2db61crjqw0-gnugrep-3.6/bin/grep checking for egrep... /nix/store/pmbv3czhsa816msq51ngb2db61crjqw0-gnugrep-3.6/bin/grep -E checking for fgrep... /nix/store/pmbv3czhsa816msq51ngb2db61crjqw0-gnugrep-3.6/bin/grep -F checking for ld used by clang... ld checking if the linker (ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... nm checking the name lister (nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... checking how to convert x8664-apple-darwin20.2.0 file names to x8664-apple-darwin20.2.0 format... funcconvertfilenoop checking how to convert x8664-apple-darwin20.2.0 file names to toolchain format... funcconvertfilenoop checking for ld option to reload object files... -r checking for objdump... no checking how to recognize dependent libraries... passall checking for dlltool... no checking how to associate runtime and link libraries... printf %sn checking for archiver support... no checking for strip... strip checking for ranlib... ranlib checking command to parse nm output from clang object... ok checking for sysroot... no checking for a working dd... /nix/store/5m4875pw1zcd588n7a6j88vwsilvnm7j-coreutils-8.32/bin/dd checking how to truncate binary pipes... /nix/store/5m4875pw1zcd588n7a6j88vwsilvnm7j-coreutils-8.32/bin/dd bs=4096 count=1 checking for mt... no checking if : is a manifest tool... no checking for dsymutil... dsymutil checking for nmedit... no checking for lipo... lipo checking for otool... otool checking for otool64... no checking for -singlemodule linker flag... yes checking for -exportedsymbolslist linker flag... yes checking for -forceload linker flag... yes checking for dlfcn.h... yes checking for objdir... .libs checking if clang supports -fno-rtti -fno-exceptions... yes checking for clang option to produce PIC... -fno-common -DPIC checking if clang PIC flag -fno-common -DPIC works... yes checking if clang static flag -static works... no checking if clang supports -c -o file.o... yes checking if clang supports -c -o file.o... (cached) yes checking whether the clang linker (ld) supports shared libraries... yes checking dynamic linker characteristics... darwin20.2.0 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking how to run the C++ preprocessor... clang++ -E checking for ld used by clang++... ld checking if the linker (ld) is GNU ld... no checking whether the clang++ linker (ld) supports shared libraries... yes checking for clang++ option to produce PIC... -fno-common -DPIC checking if clang++ PIC flag -fno-common -DPIC works... yes checking if clang++ static flag -static works... no checking if clang++ supports -c -o file.o... yes checking if clang++ supports -c -o file.o... (cached) yes checking whether the clang++ linker (ld) supports shared libraries... yes checking dynamic linker characteristics... darwin20.2.0 dyld checking how to hardcode library paths into programs... immediate checking for windres... no checking whether clang++ supports C++11 features by default... yes checking pkg-config is at least version 0.9.0... yes checking for GPGMEQT... no checking for GPGMEQTTEST... no Package Qt5Core was not found in the pkg-config search path. Perhaps you should add the directory containing ' to the PKGCONFIGPATH environment variable No package 'Qt5Core' found configure: WARNING: Qt5 (Qt5Core) not found Qt Binding will be disabled. checking for swig... no checking for swig2.0... no checking for inline... inline checking size of unsigned int... 4 checking for special C compiler options needed for large files... no checking for FILEOFFSETBITS value needed for large files... no checking for offt... yes checking for uintptrt... yes checking if gcc supports -Wno-missing-field-initializers... yes checking for _thread... yes configure: checking for libraries checking for LARGEFILE_SOURCE value needed for large files... no checking how clang reports undeclared, standard C functions... configure: error: in/private/tmp/nix-build-gpgme-': configure: error: cannot detect from compiler exit status or warnings See `' for more details error: --- Error --- nix-build builder for '/nix/store/zwf2jgy24qs7b69n1rb5pg9ywwmi82f0-gpgme-' failed with exit code 1 </pre</detailsExpected behavior To build successfully. Additional context I'm working on my flake based config with nix, home-manager & nix-darwin. I updated my inputs today & after that, I couldn't build anymore. I cloned this repo & ran which failed with the same error from I also tried this workaround but it didn't help. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata*


At: This should also add as per Gitea's docs. ( ) Without this tag sqlite will frequently report that the database is locked and cause multiple internal server errors. See
If someone needs a quick fix in `:


, CVSSv3=7.5 (nixos-20.09, nixos-unstable) CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc


, CVSSv3=9.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc


For this patch I to CudaText the global variable which you can change to False. to disable "Help / Check for updates".
OK, I will use it with next release.


Describe the bug sysklogd fails to build when built against musl-libc To Reproduce Steps to reproduce the behavior: Expected behavior Package should build. Notify maintainers no maintainers, because apparently this is ancient. Metadata Maintainer information:


I tried adding to , then running and noticed in the diff this still uses , and non-string URLs. To Reproduce Steps to reproduce the behavior: Expected behavior The diff shouldn't contain non-string URLs, and not use via . Notify maintainers
luarocks-nix needs to be updated. Its current state is messy (not clear which branch to use), I will update it.


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


Hi, I'm testing nextcloud it seem there is an issue. I'm tying to install a fresh nextcloud and with the minimal example of the man : I get : janv. 29 16:56:31 cloud systemd[1]: Starting nextcloud-setup.service... janv. 29 16:56:31 cloud nextcloud-setup-start[]: Nextcloud is not installed - only a limited number of commands are available janv. 29 16:56:31 cloud nextcloud-setup-start[]: janv. 29 16:56:31 cloud nextcloud-setup-start[]: Command "upgrade" is not defined. nextcloud-setup-start try to update a new install same result with : = [ "nextcloud-19.0.6" ]; or system: `"x86_64-linux" host os: multi-user?: sandbox: version: channels(root): nixpkgs: I may not be calling all the maintainers in case it's a false alarm :-)
I just ran into this too, with as my package. Running doesn't show an command.
I ran the command manually, and now shows up. Not sure why it didn't install through nix, though.
Thanks, it works for me too. It must certainly come from the test. I'll check that later.
Cannot reproduce this on latest master and release-20.09. Can you please give me a minmal VM config that I can use to reproduce?
Same config works in a test VM. I'll try to take a closer look next week if it's still relevant.
I am running into this error as well with about the same config as . Specifically I'm using configuration without the nginx stuff (e.g. lines 5 to 27 commented out and not set) for on both nixpkgs master and release-20.09. I'll try it in a VM and report back..
It doesn't look like the builds of nextcloud and postgres are cleaned up completely, which is where it looks like this problem is coming from. Specifically, I had built nextcloud and postgres several times while I worked out the configuration settings I wanted. It turns out there were nextcloud and postgres folders in that still remained after I uninstalled both apps. Removing those two folders, then reinstalling these programs via nix fixed the error for me.
When I've first set up Nextcloud i encountered the same issues is describing, but since then everything has run smoothly for me.
It might sense to verify the result of after the block, before executing , e.g. using and , where causes 's returncode to represent the boolean value of . The of is unclean. Instead of returning simply JSON, it also returns an informative message on the same FD: Although this should be fixed upstream in the long term (see also ), it needs to be stripped away for now (e.g. using ).
may prevent corrupted installations in some cases. But I'm still missing a minimal VM setup to reproduce.
I thought I gave one. I 'm very new with nixos but I would be delighted to learn more. maybe you can give me a link or guide me to do this? or pass the assignees to someone that can reproduce it. thanks
Well, that's the test VM's config that I already checked. Was there any existing state in /var/lib/nextcloud during your install attempt?
I don't know I need to reproduce this on the machine in question. i can try
have you checked whether repeated calls are actually safe? Especially if you want to "work out" your options iteratively. Yeah please do that. You can also answer my question "Was there any existing state in /var/lib/nextcloud during your install attempt?". This is IIRC the main cause for problems like this.
I don't have access to the machine but I've just started a vps and the same config works with the same steps. the problem would not have been solved :-) ? I'm going to look at the merge for the fun
cool merge :-) I've used adminpass = "" on vps may be this is the trick. And ok I just read other posts.
do you really need me to reproduce the problem ? it's really very easy and I know you are active in others post who explain the problem. If you really need that I have a vps whith the bug.
Well, I'm trying to check if there are any other causes apart from an existing state. Hence my question whether there was any existing state when you encountered the issue.
I don't know in any case, /var/lib/nextcloud/* seems to be the same between the 2 generations
Hit this too: I'd misconfigured the postgres database (the nextcloud module doesn't setup a nextcloud user and role on the db, which I'm used to for other modules), so the service errored out with a database "role doesn't exist" issue. Once I fixed this, I hit this problem, which went away with a good old .
To me it seems as if most of the issues here are because the initial install failed and then the app wasn't properly installed, correct? Rather than letting this stall here even more, I'd write a few more notes in the documentation.


Project description Video DownloadHelper is a "Browser extension to download videos from the Web" Metadata homepage URL: source URL: license: gpl2 platforms: linux, darwin, (windows) other build scripts
I marked this as stale due to inactivity. →
FYI, I have been trying to figure this one out from source, but as isolates the build (which means it does not allow contacting any URL to download something), and one of the dependencies totally requires going to GitHub, I'm not able to build it. I am still on it, and if building from source doesn't work, I hope the tar option works as a solution (really want to avoid the deb option).
i would recommend or to build the nodemodules from the package- lockfile. in this case, package- is missing, and must be generated with (the lockfile should be to the vdhcoapp repo ...) at least npmlock2nix allows to symlink extra files into nodemodules
FYI, I have been trying to use the methods you mentioned, and I kind of figured out how to solve that GitHub dependency issue mentioned before (had to download it through ), but now I got into an issue where I don't get any specifics of what to do, unfortunately:
I have been also trying to do it with the tar and the deb files. The tar requires an extra install step (be it for system or user), and I get the following error: For the deb, that does not require the extra steps, I can install it fine, but Firefox is not recognizing it. !
in you would do something like to create a symlink from to (i found with ) if youre stuck, maybe share your draft. this cant be too hard to build from source
Just in case, I've found this one which is way more advanced in building it. It even uses a patch to avoid using pkg (which was the issue I was having earlier). Plus, it is kind of similar to the way it is built on the AUR. The only thing is that I'm not able to build it as it is (copying and pasting it into ), so I need to see the code first and then check what can be adapted. I'd rather use this as a guide. I had already overwritten the I was using from source with the deb one.
nice! thing is, that one was made with npm2nix which generates , which should be replaced with package-, stored in the upstream repo (vdhcoapp), to keep nixpkgs small the 5KB patch can be compressed to not tested, but im feeling lucky ; )
In fact that's something neat to adapt, going to try it :) In the functional part, it seems that it is not enough to just install it, you also need to apply the part, which at least is recognized by the extension, but provides an error with no description of what to do or what caused it: ! EDIT: Nevermind, it works. Weirdly, it took a while, but now it says it recognized it. ! So the preferred situation would be just installing this and making it work as expected, instead of running that extra install step. And this is where I am not sure how NixOS masks the /usr and /etc directories where the are located.
should work with and or but i always get which is a known WONTFIX
FYI, I set this up on .
Thank you for packaging this into NUR. After installing from there I still had to do Otherwise neither chromium nor FF couldn't find it even after reboot.
Sure thing I wish I could find a way to indicate that when installing, but for now that's the only way it works. Now with 21.11, it should even work with Chrome (that specific browser was looking for a specific GLibC version packaged on 21.11).
can the NUR package be used on pure nixos given that the manifest should live under ? After installation and I still can't trick firefox into recognizing the plugin. EDIT: it's entirely possible that it's due to the fact that I install firefox via , since I can use the plugin from chromium
Yes, if Chromium is detecting the manifests after applying the user setup, then this might be something related to your Firefox setup. I will still try your recommendation.
I couldn't make it work on Firefox unfortunately (NixOS unstable with NUR package and post-install cmd)
Let's move the discussion to , as this is more related to the packaging issue. I will throw more details there.
To wrap it up - silly me forgot that I need to rerun the post install command every time (browsers?) update. Now works both on Chromium and Firefox.
posted a way for Firefox through Home-Manager to set the VDHCoApp manifests through the system installation. . With that, I'm seriously considering sending a PR to Nixpkgs, just need to check and format the code properly.
did you find time to do further work on this? you have mentioned here, but also on the issue on your nur repo that you are considering to do a PR for the app to the nixpkgs.
I have indeed, although it was more on re-running the process of creating the whole nix setup from scratch and use NodeJS 16. Now, my only concern (besides the code and many of my PR's not being reviewed) is that I don't want to keep maintaining more stuff on nixpkgs. If anyone wants to throw it, just go for it and I can help you, but personally I don't want to keep maintaining more packages because of lack of time.
FYI, a new major version will be released (2.0) and it is a refactor on the building process, which might make it easier to install compared to the way it currently works.
I curious how's the work on packaging version 2.x is going? Is there still intention to merge it into nixpkgs?
I have been trying it sporadically. The wall I'm facing is regarding the . If I skip it, I don't see anything useful to add to the output, but if I try to bundle it, I get a issue. I was able to figure out the rest though: Another option would be finding a way to replace the usage of with something else to build the file that is generated during the bundling process.
Hi, i'm kind of a nixos rookie so sorry for asking, but: i tried installing the coapp first via but firefox did not recognize it (loads forever), so installed it via NUR, but now the browser wants me to update the coapp (which is pinned to 1.6.3 here it seems) so: how can i update this? ( i tried cloning it but running fails as node2nix runs into )
currently there is no way unless you can get 2.X packaged. As mentioned on the comment above, I'm struggling with the bundling process that uses to get the new binary.
ok, thanks for the very fast reply! hmm thats unfortunate im rather busy the next week(s) so i can only keep my fingers crossed and hope you'll find a way in the unlikely event that i figure out a way after that i'll keep you posted thanks for the efforts Edit: but in case i find time, will your current efforts be publicly available somewhere? (not just the , but a more complete repo e.g. also containing )
Sure, you can find it .
I was trying to get your 1.6.3 version working with 2.0.x, but I'm very new to packaging in nix and didn't get very far. So, I'm glad to hear that you are working on it. Good luck and let me know if I can help test in any way.
Hi, If anyone can add release 2.1.9 Best Regards
, there is a reason version 2.X still hasn't been yet.
Good news everyone, someone figured a way to package it and it's working, so I just adapted it to work the nixpkgs way. If you are interested in pushing it to nixpkgs (I really don't want to maintain it), you will need to pack (could be internal to the same vdhcoapp package) and .
Im not experienced enough and/or attached enough to NixOS yet to take that on, but i would really appreciate if someone makes it happen. If i get into NixOS more in the future, i would also be willing to take it over at some point if needed
well done! Im not very experienced either, but i use nixos as my main system so at least im attached enough ;) i will try pushing it to nixpgs (as my first contribution) today


Describe the bug fails to build on master and unstable Notify maintainers
could you please take a look at ?
Thanks


Describe the bug I'm adding gimp like this in 20.09: However the fourier plugin is not being recognized. It should add: Filters/Generic/Forward FFT Filters/Generic/Inverse FFT But these filters are missing. Expected behavior FFT plugin should be recognized by gimp. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:
I'm not sure about these specific plugins, but gimp-with-plugins comes with G'MIC, which includes a FFT filter under Filters -G'MIC Qt... -Available Filters -Frequency -Fourier transform


Describe the bug Failed to build . To Reproduce in -rebuild switch Expected behavior Build successful. Screenshots  Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
New warnings/error are introduced with new GCC releases.
could you please give a try?
Yes, it works.


Describe the bug I have a nextcloud installation in the vhost root: which would redirect to for the NextCloud login. Also I enabled in the nginx settings that a SSL certifcate with the acme service should be used. However, no certificate can be issued - acme claims that it gets 404. To Reproduce Steps to reproduce the behavior: nextcloud and acme configuration to your configuration nix. E.g. will generate a nginx config that contains: first part of that configuration snippet also matches for the folder and hence a 404 is returned. Expected behavior Having SSL cert issued by Let's Encrypt. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Opened with a fix.
Thanks for the quick fix :)
can you confirm that this fixes the issue for you? If so, I'd merge+backport. Just in case you didn't know - you can do
I did manually edit the nginx config in the nix store: Then run the acme command as standalone: So it works.


, CVSSv3=7.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc


Describe the bug AdGuardHome has the meta platform , but is a . To Reproduce Try to run on (or any architecture other than ). It will fail with : Expected behavior should execute, so that it can be used. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
I will try to get it instead of pulling a pre-compiled binary, but I'm not sure whether I'll get this solved. EDIT: Okay, that looks to be above my packaging skills, as the project consists of both a node component and a golang component, so it's nontrivial to package. An intermediate solution might be to use the architecture to determine the download URL, but that would make the src (and thus the hash) depend on the architecture. The downloads for different architectures .
Hotfix for aarch64 by using :
I marked this as stale due to inactivity. →
I also have the problem from the thread starter and I was wondering whether there is now official support for aarch64 (trying adguardhome on raspberrypi 3) or do I need to change smth in my config. I just use adguardhome as the inside of the systemPackages and I enable it. I also see this PR: .
the pr wasn't backported to 21.05. the pr will be in the 21.11 release which will be released today or tommorow afaik
great, thx for the info :)


Describe the bug As of this commit the package no longer allows overriding the JRE without failing to build. It still worked as of this commit To Reproduce Note that is the content of the in the above commit. note it also fails when overriding with however which is the current java15 version works. Expected behavior Successful build of SBT Additional context Non Debug output Notify maintainers Metadata Maintainer information:


Describe the bug Nix installs a version of Chromium with Widevine on NixOS, despite not being enabled and goes through unfree license checks. To Reproduce Steps to reproduce the behavior: to system configuration in Chromium Expected behavior Widevine is not installed if not explicitly enabled. or Chromium trips nonfree license checks and forces user to allow unfree packages. Screenshots ! ! Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(patrycja): channels(root): nixpkgs: Maintainer information:
Chromium downloads the binaries itself and stores them in It looks like it's a known issue:
Oh, that's bad... :o Seems like Debian fixed this with a custom patch () but from your linked issue that doesn't seem really good either: It won't remove WidevineCdm automatically for existing users It won't be updated -vulnerabilities will never be fixed (which is very bad!) It might break other stuff: I don't think this applies to us though ( should manage it via the Nix store) Brief update: is also present on my system: ! Apparently not but looking at this version is already more than one year old! I cannot get any DRM demos to work so maybe the code will only download the binaries but not execute them (which is still bad but at least a bit better). https://shaka-player-;textlang=en-US;uilang=en-US;panel=HOME;build=compiled This even happens with chrome://settings/content/protectedContent set to "Blocked". It's disabled then but it will still be (re-)downloaded automatically.
I've submitted this to upstream: Let's see what happens.
If you set enablewidevine you need a license to distribute it. See Over to the encrypted media folks to comment, but this sounds like WAI. Does Nix have a Widevine license? If Nix does not, and Google is unwilling to change how Chromium and Widevine are licensed together, the best course of action IMO would be to disable it in Nix's binaries (ie. if enableWidevine is false, enablewidevine is unset. If enableWidevine is true, enablewidevine is set and license is changed to unfree.) I understand that building Chromium is not something the average person can do on their toaster, but I don't think the group of people that need Widevine and are unwilling to use the official proprietary Chrome binaries is very large.
I marked this as stale due to inactivity. →
I am unable to reproduce this more than 3 years later on M124. Closing this, assuming this has been fixed a long long time ago.
I can confirm this is still an issue. Followed instructions in OP.
Okay, thanks, I managed to reproduce it now. Might have been a fluke or specific to my use of back when looked into this before. I want to clarify that this is not violation of the BSD-3 license uses. I do however understand that some prefer having not download additional unfree blobs.
There is now. It disables the automatic download and prevents previously downloaded blobs from being loaded and executed. With that PR, Widevine only works when going through the wrapper (). I hope this resolves the concerns raised in this issue here and makes both non-DRM and DRM users happy.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Describe the bug After electron 12 came out, adding in home-manager succeeds, but trying to start the app fails mentioning a missing javascript function from an older version of electron. To Reproduce Steps to reproduce the behavior: to home-manager's app from terminal with Expected behavior Expected the application start as it had before. Additional context I was able to get it working locally by providing an overlay to home-manager: I would have created a PR myself, but I'm still new to nix and not sure entirely how to require a different electron version in the package derivation. Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(jon): nixpkgs: Maintainer information:
thanks for catching this! Just fixed in the PR above.


Describe the bug In , the path /usr/share/applications is hardcoded, the only way to change it would be to patch the package. However, from I see that the Debian package is used, so fixing this in the source code would require not to use a binary version (I guess). To Reproduce Steps to reproduce the behavior (tested with the package from the channel): the GUI client using the command the following error be thrown in the console: Expected behavior The autostart file is properly symlinked to the nix store package. Additional context I found a dirty fix for this issue, enable the preference and run: However, note that disabling this preference will replace the symlink with the one throwing the error. Notify maintainers Metadata Maintainer information:
I always use sway and just started it that way on launch so I didn't notice. This will probably, as you said, need a change away from the pre-built package. Right now I'm quite busy, but I'll do it soon. Will tag you in the PR so you can test (as I can't...). Did the dir exist before changing the setting?
Hey, I'm working on the client daily, and I'm doing so on NixOS, so maybe I can help with this. Building the package might be a bit involved, since our is a bit involved ,and it relies on a rust toolchain installed by , although this could be worked around with some bash magic to just drop the argument. I personally just have a somewhat involved for building the daemon and then separate FSH environments for running electron builder, but that's because I'm also trying to build for Android and do weird debuggy stuff.
Yes it did since other packages created their own entries beforehand.
Thanks for the insight, So, is this an issue that might make sense to fix in the mullvad-vpn project itself? If not, could you please send me your so I have some guidance when building it?
I must apologize for the hiatus, but life happened. I've been playing around with a somewhat cleaned up nix shell for building all the things for a proper nix package, but there's still some manual labor required. The shell that I use is somewhat similar to , but mine has far more cruft to also do android stuff. And this one could very well be slimmed down further too. The FSH environment for node is a vain attempt at making and work better, but to make things work, there's still some manual labor involved. The weird wrapping of is there because all the app's build scripts expect rust to be installed via rustup, whereas I use an overlay - so the nix script could be simplified. As long as the rust compiler is new enough, I think the app should build. To build the app, there are 6 parts that need to be built: for when the kernel module is not loaded, built via . Just executing that script on Linux should work just fine. the daemon, the CLI, problem report tool and OpenVPN plugin, should be buildable via , but the binaries end up being quite chonky, so they should all be stripped. Shell completions, the following snippet is copied verbatim from script. Download the relay list via Download the API address list via the electron GUI, built with an gulp that eventually invokes listed is basically a list of things that you must build or adjust so that they work in NixOS. Ideally, one would be able to just invoke , but due to  not building on nixOS (fails due to a node-gyp builder failing to find python) and producing an and a package, some patching would be required. It'd be great if a nix-npm wizard would apply some arcane knowledge to make build, otherwise it can just be removed from , as it's strictly a macOS dependency. Another change you'd probably want to make is to make make an unpacked build rather than producing RPMs and DEBs. The electron binary that's downloaded via will also not run. A dirty hack that I use to make it work is to just replace it with NixOS's one - , but this is not what the app developers are testing against, so there most certainly will be dragons. We build statically linked OpenVPN and Shadowsocks binaries, and those are found in  submodule. I assume these should be patchelf'ed so that they can be used on NixOS, but it seems like just using is not good enough, but doing what the current derivation does will most likely do the trick. These binaries may be substituted with NixOS native counterparts, but they wouldn't necessarily be equivalent - Mullvad's OpenVPN binaries have some patches that upstream are not interested in and we also try to build the minimal amount of features along with a minimal build of OpenSSL supporting only the ciphersuites that Mullvad servers use. I don't believe we have published the keys we use for signing commits currently, I'll see if we can make that happen. Currently, all the release commits are always signed by the same person - but this may change arbitrarily. After having written all of the above, I'm not entirely sure if making a native package would be worth the effort, given that I can't guarantee that any of the above won't change often. Maybe the best bet would be to make a minimal patch to get electron builder so that can just run. It seems to me that it's only electron/node related scripts that fail on nixOS: the GRPC buildscript fails because it expects to be able to call a downloaded binary from building fails when running probably some other electron quirk The commits are signed by individual developers, the keys are available , one should also make sure to check if the signatures are valid.


Project description On some installations this simple text editor even has syntax highlightning, but it might require non-trivial amounts of work to get that part to work. Metadata homepage URL: source URL: Gitlab, , tag = or alternatively: latest current version: 1.2.2 license: MIT (according to the ebuild in the Gentoo repository) platforms: at least linux, but might also support other platforms with X11 support
I marked this as stale due to inactivity. →
I still need this.


The package hard-codes various X11 libraries as dependencies while making many other features optional, including GUIs. It would be nice to have an option to disable the X11 feature and the related . The use case I have in mind is installing a custom Vim on a remote server. Pulling X libraries, even without enabling a GUI, adds a few dozen megabytes for something essentially useless. An approach is doing something like this: but it doesn't feel very clean... Any thoughts from or ?
I agree. It would have been nice if these X dependencies would have been to only if is or .
/me whispers neovim~~~
I'm all for testing new things and neovim is on my list. But according to , the neovim package pulls 428MiB of dependencies, half of which for Ruby, the other half for both Python 3 and Python 2 (seriously?). Is there a way, by any chance, to configure neovim to avoid this bloat ?
admittedly I've never tried to configure a mininmal version but one can unselect these ecosystems:
See .


Project description a mining pool, maintains a fork of XMRig which adds the benefit of automatic algorithm switching. I have created following overlay which seems to work fine. The question is if anyone is interested in having it implemented as a separate package, replace the , or if it should be integrated as an option to a new XMRig systemd service (which would also be a nice-to-have, such as ) Notify Maintainers: Metadata homepage URL: source URL: license: gpl3 platforms: linux, darwin


Describe the bug creates a defect as the block is defined two times. To Reproduce Steps to reproduce the behavior: Enable and Expected behavior and should be merged to one block. Additional context I'm on zfs. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(plumps): channels(root): nixpkgs: Maintainer information:
I have a PR up to fix this


Describe the bug failed to build on master. To Reproduce Steps to reproduce the behavior: nixpkgs master Expected behavior It builds. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(oxa): nixpkgs: Maintainer information:


Describe the bug Browser page fails to open if no installed on the system. To Reproduce Steps to reproduce the behavior: teleport using SAML (might need enterprise license) using tsh + SAML errors thrown, but the browser page doesn't open Expected behavior Browser page should open and ask for credentials. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:


Describe the bug A clear and concise description of what the bug is. The and python scripts in need their interpreter to be patched (and the module available). To Reproduce Steps to reproduce the behavior: Expected behavior A clear and concise description of what you expected to happen. They should work :stuckouttongue:. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(bt1cn): nixpkgs: Maintainer information:


Describe the bug wendy, one of the big-parallel build hosts used by , cannot successfully build This blocks advancing nixos-unstable. To Reproduce Steps to reproduce the behavior: wendy to build Observe :( or, more realistically: the attached CMOV16rm-, and run (a reduced commandline that produces the same assertion failure is ) Expected behavior A clear and concise description of what you expected to happen. Additional context The assertion that's tripped by this YAML file is: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
is the CMOV16rm- (can't upload it here because it's not a supported GitHub filetype, apparently). To be more precise, the test that is failing is this one:
This has primarily become apparent because the configuration was changed in NixOS/nixos-org-configurations to make wendy only build big-parallel jobs. Since llvm is big-parallel, this means that wendy will now usually get selected for building llvm, since the load is otherwise pretty low. Previous successful builds of have been using one of the packet builders instead, which are using a newer CPU for which LLVM has a scheduling machine model.
FWIW, this probably affects other LLVM versions as well, but they have current versions in the cache. If wendy rebuilds the other packages (e.g. stdenv bump or something), they'll likely start failing as well.
If you spin up a VM using the CPU profile that at least virt-manager calls "OpteronG1", then you can reproduce this using the LLVM tests. That's not quite the same as the CPU reported on wendy (OpteronG1: k8-sse3; wendy: amdfam10), but it exhibits the same problem.
I don't know why, but wendy as disabled now.
it's probably late for you (I hope I didn't confuse names), but you this issue some time ago.
uh, same full name but this GitHub name is in .
Filed upstream for this.


Describe the bug when using , only gets set on linux. This seems to be done very much on purpose, so I don't know if there's some good reason for it: This causes problems for instance when cross-compiling to windows and then using pkgsStatic, some packages wrongly think they are not compiling statically. I can't remember what packages I've encountered this in, and right now I'm encountering it in a change that I'm trying to make, not something that already exists. To Reproduce Steps to reproduce the behavior: Expected behavior would be true on all platforms if using Notify maintainers seems to have this code / created Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(qolen): nixpkgs: Maintainer information:


Describe the bug On current nixos-unstable (), fails to build To Reproduce Steps to reproduce the behavior: -shell -p ophis Notify maintainers


Describe the bug The Airsonic service fails to start. To Reproduce Steps to reproduce the behavior: = true; to your config. reveals the following error: Cannot load configuration class: which causes the application to enter a restart loop. <details<summaryError trace</summary<p</p</detailsExpected behavior It doesn't error, and instead runs successfully. Additional context It doesn't seem to be due to an Airsonic update that this started to fail, so my guess is that something got changed with the JRE. I think Airsonic will only work with JDK 8 (see: ), but I'm not very familiar with how Java works, so I'm not sure. Notify maintainers Metadata Fails on both of the following systems: Maintainer information:


Describe the bug Unbound allows the "include" directive to appear more than once. : However the type definition of is too strict. This code raises an error: Notify maintainers Metadata Maintainer information:
Could you provide me with the value you set the option to?
An example has been provided above. Simply set to a list of string. The service will fail, but it should work. You can try
Ah yes indeed, sorry I didn't see that. I'll open a PR that fixes this.


Project description Add Youtube Music Desktop player Metadata homepage URL: source URL: license: Creative Commons Zero v1.0 Universal platforms: linux, MacOS Similar application to Google Play Music Desktop:


On NixOS 20.09, steps to reproduce the behavior: setting up wireguard, change to another port still shows the old port:
This seems to be fixed by my PR


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


Drone 2.0 has been released: <!-- Note that these are hard requirements --- name: <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 1.10.0 desired version: 2.0.0 Please tag this issue in your PR.


[ ] It's likely that kodi/xbmc remains vulnerable. [ ] Audacity on 15.09 is older, so the patch used on master doesn't apply and wouldn't be enough anyway.
Well, the two minor issues above remain, so I'll leave this open ATM.
Closing as 15.09 has now been superseded by 16.03 and kodi is using ffmpeg 2.8.6 since


Describe the bug On NixOS and some other Linux distributions like Fedora is world-read-writable: This is not the case on other systems like Ubuntu and others from the Debian family, which instruct their users to get access to by adding user accounts to the group: When building a derivation that uses , like for example NixOS Tests or on such systems with Multi-User Nix and KVM installed, the build fails with an error message similar to this when booting the VM: To fix this users might try to add the users to the group, which has no effect because of the build sandbox. The only effective fix seems to be changing the permissions for to be world-read-writable: This fix is difficult to find for users that are not already very familiar with KVM (like me). Proposed fix Nix should detect the situation where a build is run in the sandbox and the permissions for are going to lead to a failure and emit a warning or build error that points people towards a working fix they can manually run. Potentially it would even be possible/desirable for the build to proceed without KVM/hardware acceleration, but I'm not sure because of the terrible performance impact. To Reproduce Steps to reproduce the behavior: a system that supports hardware virtualization ubuntu or another affected distro KVM (see for example ) Multi-User Nix a derivation that uses You can also manually change the permissions to to reproduce the issue. Expected behavior A more user-friendly failure mode, like what I wrote under proposed fix. Additional context There are also documented examples of other users running into this: and maybe also There is some relevant discussion here about the security impact of that permission change: Notify maintainers There are a lot of other people in git blame. I you two for now. Hope that's OK. Maintainer information:
VMs already proceed without hardware acceleration if KVM is not installed at all. I tested this with NixOS Tests on with NixOS. At least for that case the relevant code I found is this: I will submit a PR which fixes this check so that VMs also proceed without KVM in the scenario described above. I am not 100 % sure if that is the best fix and if it should close this issue, because firstly I think it would be good to make users aware when KVM is not enabled, when the hardware/software support would allow it: because it's not installed or because the permissions are broken. What would be a good way to emit such warnings? Secondly I am also a bit confused about there being flags for hardware acceleration here as well: This makes it seem like is treated inconsistently with other architectures and I don't understand why.


, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
09 is EOL


Describe the bug Papermc crashes due to an incompatible Java version To Reproduce Steps to reproduce the behavior: Set Log Excerpt Additional context The vanilla package runs without issues. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(johannes): channels(root): nixpkgs: Maintainer information:
I couldn't reproduce with this test driver : <details</details
I also get this. I think papermc starts supporting java 16 with build 668 (at least it seems to start working for me after that build), but the current build in nixpkgs is 488 building the latest build (771) works for me. the test you defined doesn't wait long enough to actually start the server Which I think you need to run with since it requires networking to download the vanilla minecraft jar it will then patch. Now the test fails as expected complaining about the java version. But if you overwrite the papermc package with: the test will succeed. (btw is there a smarter way to overwrite these variables?) Metadata: system: host os: multi-user?: sandbox: version: channels(root): channels(kaine): nixpkgs:
Same thing happens with multimc and the new version


Project description A system for automatically configuring mutt and isync with a simple interface and safe passwords Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin


Project description The terminal is already packaged in nixpkgs. As foot uses its own terminfo, this terminfo is needed on any remote servers you connect to using foot. It would be useful to have this terminfo packaged as its own output as with other terminals: alacritty, kitty, rxvt-unicode to name a few. ping foot maintainer for feedback Metadata homepage URL: source URL: license: mit platforms: linux
That is a very good idea! Unfortunately it doesn't seem to be possible to specify a separate install directory for foot's terminfo so far (it is installed to along with the license etc.). I'll open an upstream ticket, they are usually very helpful, and then we'll be hopefully be able to set this pretty soon.


Describe the bug Building or fails with: To Reproduce Steps to reproduce the behavior: until approximately 70% (sometimes a few percent earlier) Additional context Compilation log for with only : Compilation log for with only : I had this problem with Sierra with XCode 9.2 also. I just upgraded to Mojave 10.14.6 and XCode 11.13.1. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(peterhil): channels(root): nixpkgs: Maintainer information:


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


Currently, we first build a derivation containing the unpacked Chromium source code, which is then passed to the actual Chrome build. This is very inefficient: the unpacked source tree is 1.8 GB and ~85K files. Copying these between build machines can take a very long time: for instance, the is currently showing two builds (in the copying state) which have already taken 22 hours. So it would be better to do whatever does in the derivation.
didn't we do this because IO was too slow for unpacking in NixOS tests?
I don't think the tests need the source code.
Is there another way to avoid copying source derivations between machines? I think the source derivation is good to keep, I want to have QtWebEngine which uses chromium, would be nice to use chromium source and all patches that is used. Would this still be possible (in a easy way) if chromium-source is removed?
The derivation could create a (compressed) tarball. That would help a lot since then Hydra won't have to do a huge amount of random access I/O reading/writing lots of small files.
The reason I've done it that way was to separate bundled dependencies and the sandbox from the main source, so for example if we want to build just the sandbox, we don't need to extract the full Chromium source. But I'll look into it so we can find a better solution, right now it's not working as I had in mind back then, because the source is copied into the temporary build directory, but a better solution would be to not copy anything at all.
I don't think you can re-use for this, as Qt uses a rather heavily modified version of the source.
Great point. I will add too that even if it was vanilla, chrome source moves far too quickly to be a dependency of a qt component. QtWebEngine is; I suspect using their own fork of the blink fork of webcore (webkit.) (webengine) If we look at the chromium release schedule they are trying to hit a release almost every month. If someone is quick (Before 19th of this month) they could apply for a gsoc to possibly get this chromium work done (worth a try?)
With S3 and decentralized hydra, we should really combine the source back. Currently this is blocking a channel update:
Working on this right now.
I've also the relevant changes to .
There's reference to the old path of the file on line 33 of this file:


Project description The driver supports Realtek 8852AE, which is a wifi card for some new laptops. Without the driver, the wireless interface would be missing for those computers. (My new Lenovo laptop uses this card and I cannot connect to WiFI currently... I'm not entirely sure how to package this) Metadata homepage URL: source URL: license: GPA 2.0 platforms: Linux


Describe the bug With the latest kernel and the latest non-beta nvidia driver, the drivers don't compile: To Reproduce Steps to reproduce the behavior: unstable the latest linux kernel nvidia as a drivers Expected behavior It should compile. Notify maintainers Latest person who touched it: Metadata
I can reproduce this issue, albeit I am using stable channel with the latest kernel.
tl;dr for everyone facing this: should serve as a temporary workaround
I think we should implement some kind of kernel version lock for the nvidia driver to prevent such occurrences in the future.


I get the following output from :
Thanks, So fast. :)
This one was rather easy :-)