I am new to nixos... When I try to use printScr Key on keyboard. it not responding. non of the printScreen optins working.. Steps to reproduce the behavior: ... press Key PrintScr ... ... Should take a screen shot ask for location to save to. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
I am not too sure but according to the , cinnamon does not have a "native" screenshot tool but gnome-screenshot could be used. I am not too sure if enabling cinnamon auto includes gnome-screenshot. If it doesn't you can just add it and see if it solves your problem.


I have user-installed Cinnamon applets, desklets, extensions, themes, which have been installed in the home folder by a different OS (as far as i remember). Many of them work under NixOS (some do not: ). However, i cannot update them. When i try, i get the message: The same happens if i try to install a new applet. Steps to reproduce the behavior: up Cinnamon desktop on NixOS and log in. to install an applet. Should be able to install and update user-installed applets, desklets, extensions, themes. ! I am just beginning to switch over to Cinnamon from GNOME 3 (having been fed up with GNOME, especially under NixOS).
Installing [][gettext] that provided solved the issue. Shouldn't be a dependency of Cinnamon desktop then? [gettext]:


Describe the bug building the package fails. To Reproduce Steps to reproduce the behavior: and wait Expected behavior Successfully building swift to be used. Notify maintainers Maintainer: Last 4: … Metadata Error
Seems as is used for building rather than . Probably happened during experiments to declare . Apart from that I'm not a swift maintainer, so if the issue is more complex, I can't help I'm afraid.
I think the Python warning is actually benign. I see a build error related to a change in the handling of . Commit appears to break it for me. I can offer a , which you can try like this: But I am not sure what the proper fix is. I would like to ask for comment.
I have pushed a new fix to my . This uses the proper fix as suggested by It would be nice, if someone can confirm it works. I have also opened PR with this fix.


Project description Formatter for rst (reStructuredText) files Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, ...


OpenSCAD seems to be built without support for PDF exports. (This is a very useful feature to print projections on paper to check the dimensions of a design for example). Version: OpenSCAD version 2021.01 On nixpkgs: master (2022-09-18) Open OpenSCAD Go to File -Export -Export as PDF… Save to some file Observe the following error in the OpenSCAD console: CC package maintainers:
Any idea what dependency they need for PDF? (image file export has been enough for me so I never looked)
I think cairo. (I was looking into this earlier today.)
Yes, cairo was missing:


Describe the bug Running fails with To Reproduce Extra info On of that script scopeoCmd isn't called correctly. Seems like introduced the problem in this PR


"ownCloud Infinite Scale Stack" or owncloud rewritten in Go. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: asl20 platforms: unix
There are some hassles to deal with on this one. PNPM usage: Image assets downloaded with curl (and no hashes or revisions) Code generation tools and code repositories downloaded by
Note that ownCloud provide prebuilt binaries for oCIS. It's fairly simple to get these working on NixOS: Perhaps this can be used as a temporary solution until we can build it ourselves?
I used your derivation and opened . I tested it a bit, and will work on a proper module over next few days/weeks, can you share if you are already using above derivation, and if yes, how stable are rc releases?
I've been using the rc for a while and haven't had any major issues. It's probably better to go with the stable release by default though. Perhaps we could package both?
Has the situation changed where the OCIS can be built from source now? I'd rather not use a proprietary binary.


Configuration snippet like this: yield a configuration like: However nbd-server expects section to always appear before export sections, otherwise it complains about not being able to find general section. I'd say this is upstream's fault because this order should not matter, but here we are. section to always appear before export sections. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
This looks like it should be easy to fix. I'll probably get around to it tomorrow morning.
For reference, the error looks like this:


Project description Neofetch like tool that can lookup IPs. :earth_americas: Metadata homepage URL: source URL: license: gpl3 platforms: posix shell
I'll do this myself.


When I update nix I can't copy to our binay cache anymore. All I get is I bisected nixpkgs and found that the bug was introduced by . Run The parent commit works: This error here is fine because our cache has a different name of course. Please run and paste the result.
Just wondered if here is the right place for the issue but I’m quite lost on this. Maybe this is a nix bug?
No you're correct to open this here, this is a good place to start. I'll try to bisect further to see which aws-sdk-cpp commit broke this functionality, hopefully that will tell us more about how to proceed.
Bisected to , but unfortunately the commit is very large so I don't see an obvious cause. Maybe it's best to take this upstream to the Nix repo now.
Thanks for reporting, and sorry if this broke your workflow. I've bookmarked this issue and I'm going to look into adding an installCheck regression test to ensure s3 stays functional on future updates.
Thank you all for the quick response. This was a really sneaky one. Luckily nix allows rollbacks. That would be great. I’m sorry I cannot think of anything better than checking the error message of . When I do I let you know.


I have installed a very barebones server with NixOS. Whenever I run it shows the following warnings: I get that it does not matter that much which of these are used, but it makes these commands not very transparent. Why is being used from and not , while is apparently part of ? Should we make sure these packages will not both be part of or should we make sure the files are only available in one of the two packages? up a minimal version of NixOS. the log
These are usually fixable by just setting priority values. coreutils should probably have a lower priority as they are usually cross platform but not as many supported features. The getconf and getent are interesting because they are actually symlinks to glibc. But we might as well make unixtools lower priority as well.
Is this something we should do nixpkgs-wide? Will that avoid the warning messages? I was thinking why these are providing the same files and why both packages are being used. For instance, do we really need openresolv or is that included unintentionally? The priorities is a way to solve this safely, but I feel like there shouldn't be any conflicts for the base packages at all.
Maybe openresolv we can leave out of systemPackages. But, some of these collisions are kind of unavoidable. We need both procps and coreutils even though they both provide kill bunary. It might be interesting to see which other distros use but IIRC they are almost identical
For coreutils, ArchLinux seems to leave out the kill binary: This also feels a bit wrong, as it isn't the original package anymore. Changing the priority does indeed sound like a better option. Coreutils should have a lower priority.
I tried giving coreutils a lower priority, but it doesn't seem to have made a difference for those warnings.
oh it already has lowprio: but it doesn't really work when everything has the same priority.
systemd-resolved is not enable by default so resolvconf shouln't be really pointing to resolvectl. I think the dummy command provided for compatibility doesn't work correctly if resolved is not running and dhcpcd needs it to configure interfaces.
Should we just give openresolv a higher priority than systemd?
Yes, correct.


The dhcpcd resolvconf hook check if resolvconf is installed and, because the command is in the PATH, it won't fall back to writing directly but will attempt to execute something like this: echo 'nameserver 10.0.1.1' | resolvconf -a wlan0 Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
Reproducible way to see these collisions: With a file set to I ran in the (the latest commit on the branch), and I get these collision messages:
ping
Hi all nixos-version 03. (Koi) I have the same collision on kill gnutar resolvconf but also on collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.


0/share/icons/hicolor/48x48/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/128x128/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/64x64/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/22x22/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/16x16/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/scalable/apps/phonon-' collision between /nix/store/mrfyscriilpbyqvnfpgwa87ly4hky3jr-phonon-backend-gstreamer-qt5-4.9.0/share/icons/hicolor/48x48/apps/phonon-'
This seems to include many more collisions than related to this issue.
Maybe rather than changing the nix-env priority, a better solution is to remove some of these programs (e.g. delete in util-linux's ).
That seems hacky to me. What if you want util-linux's version of kill? Presumably if the maintainer thinks it's worth including, someone has a use for it. Nixpkgs shouldn't be making these decisions at the derivation level. Something like meta seems ideal because you can change it without effecting the derivation.
Since and were merged, does that mean this issue can be closed now?
I think so, I don't see these collisions anymore.
Let me know if this isn't fixed after all.
sorry, but i see these collisions.


it's a different issue: it seems you're installing both the wrapped and unwrapped version of the same packages. I'd say there's something wrong with your configuration, but if you think otherwise open a new issue.


Package name: wasm-bindgen-cli Latest released version: 0.28.4 Current version on the unstable channel: 0.2.84 Current version on the stable/release channel: 0.2.84 Notify maintainers and I'd really appreciate an update it's causing me problems with a trunk build similar to Note for maintainers: Please tag this issue in your PR.


The package (and the related ones) don't offer completions, only Npm's. At least for bash Node offers it through . I'd like this bash completion to be . Install Node, see that there is no completion in the completions dir (I'm using home-manager, so that'd be ).
Fixed by


none Please run and paste the result.
I started to bisect this with at nix started to download ~4GB of derivations and I aborted the process. The is
it seems like the issue already got fixed upstream in but there is no new release yet. We either have to target commit which contains the fix, or wait for the new release.
you are right, pdfpc/pdfpc fixes this. I tried it with this patch on nixpkgs:


Describe the bug I copied a closure from one system (19.03) to a USB thumb drive and from that to another system (19.09), but the program don't work. I think nix packages should be pure and work also on another system running a different NixOS channel. (Right?) To Reproduce Steps to reproduce the behavior: sweethome3d installed in thumb drive thumb drive (i use pantheons files app and open a terminal from there, then ) a folder on the thumb drive. mine is "nixpkgs" to that folder: the nix store path of the program: the usb drive into another system and mount it, get the path the nix store path to your system: you can install it for the current user if you like: or just open a nix shell: run the program: Expected behavior Program just work. Additional context I moved to a new flat with most of my computers and want to plan where to put my furniture. I installed sweethome3d on my notebook, but it is not powerfull enough. So i want to copy the program to my iMac. I have internet from my tethered mobile phone, so i can't just install it from the internet! sweethome3d is about 500 MB, that would be 1/4 of my data plan!!! Metadata X230: system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs: imac: system: host os: hangs after that Maintainer information:
Looks like this problem again: cc
When i run the package from unstable on stable, i get the same error: (but it will hopefully work on the imac when i copy it there again)
I get the same error when i run the package from unstable on my 19.09 branch. So it might be generally broken on unstable.
Yes, looks like be some kind of impurity. It runs on my NixOS 19.03 system, both from the stable and unstable channels. And I did the "nix run" thing you said and it works there too (I'm not sure how much isolation gives, apparently not enough).


It looks like the program copies some so files to on start-up: Two of the programs match to libraries in the but I could not match the other two; also I do not have the same filenames as you. Not sure what libraries’ RPATH should be patched but perhaps adding the following to wrapper would work as well:
For the reference, the libraries loaded are listed here:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .


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


Since May 10, .NET 5.0 is EOL (End Of Life), and should not be used. Should it be marked as EOF similar to dotnet 2.2 and 3.0? See All packages using dotnet 5.0 should be updated to use a newer, supported version. These packages still need updating: [x] - [x] - [x] - [x] pkgs/development/tools/build- - [x] -
There is at least one package, which currently uses dotnet 5 sdk - . So we will need to update it beforehand. Btw, I'm not sure if we have any policy regarding packages removal, for nixpkgs in general or specifically for it's dotnet part. , what do you think?
The package is also using .NET 5: . But this is because I made the PR upstream updating it from .NET 4 to 5. I suspect that the transition to 6 will be similarly easy.
I think we should just mark it as depricated, as many projects do still use it upstream. Dotnet version 3 is also still commonly used, so I dont expect it would be realistic to remove version 5 any time soon. also uses dotnet 5 by default, I'll go ahead and switch that over now. See . That doesnt mark dotnet 5 as deprecated or change anything from a SDK perspective, just some preperation work.
See as well, it adds a warning whenever dotnet version 5 is used. Not using a throw for now since a few packages depend on it and I dont have the time to clean that all up at the moment.
Can you provide a list of packages that need updating?
Based on a quick grep: pkgs/development/tools/build-
I believe that after all the above PRs are merged, we should be able to safely remove .NET 5 from nixpkgs :)


Source no longer apparently available from upstream website. They recommend using pypi. Attempt to build , as in :


Project description A simple server for sending and receiving messages in real-time per WebSocket. Includes a web UI, also has an Android client for receiving notifications and an optional CLI program (distributed separately) for sending notifications. Metadata homepage URL: source URL: license: MIT platforms: anything Go runs on
I started an attempt locally, however it failed due to some timeouts while fetching Go dependencies... will retry during this week :)
I think the main difficulty is the UI, which needs to be compiled with NPM. In essence, I think the build is three-staged: fetch UI dependencies, fetch Go dependencies, do the actual build.
You may want to take a look at .


The ssmtp program is dead/unmaintained. The commonly suggested substitute is msmtp. While [home-manager has a module for msmtp][1], NixOS lacks one. [1]: Let's: [x] Done in We should probably also: [x] Remove the ssmtp NixOS module and add migration instructions to the release notes () [x] Remove the ssmtp package ()
I marked this as stale due to inactivity. →
The module works really well. Thanks for the module


Mainline / hardened / testing / ... kernels can be painlessly modified via : Sadly, this does not work with a bunch of other kernel variants: All kernels should honor I am not entirely sure how dynamic binding is implemented in kernel stuff, however slightly changing xanmod parts this way seems to fix : zen and lqx look similar to xanmod, no idea about libre Pinging people who seem to update affected packages often Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same underlying issue as it seems
Can confirm that this patch fix the issue for zen and lqx kernels:
have you submitted these changes as a PR that I can review?
sorry for the late response. I created a new PR with this changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Looks like it now uses .NET 8 which probably made all existing plugins incompatible - Package name: ArchiSteamFarm Latest released version: 5.5.0.11 <!-- Search your package here: --- Current version on the unstable channel: 5.4.13.4 Current version on the stable/release channel: 5.4.12.5 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The package/module has no official way to use plugins, so there is no way to use them unless people are using overlays which should be constructed in a smart way to re-use the same methods as archisteamfarm does. Anyway, here is the update


Project description This flag is available in most other major distros. It is necessary to enable screen sharing on wayland inside of chromium, combined with xlr-desktop-portal-wlr and pipewire. It requires the build flag and a dependency on libpipewire02. See as an example. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ...
that would definitely be nice to have :) I actually also noticed this but unfortunately cannot test this easily as I'm not using screen sharing. If you could contribute a PR that would be awesome (but be aware that Chromium does unfortunately take quite some time to compile). Alternatively (but less preferably) we could make the required changes with the next update and test the core functionality (as always) and you could test screen sharing after the new version is available in the binary caches. Additionally we would need to package in Nixpkgs to make this work on wlroots based compositors. On Gnome/KDE this might work out-of-the-box, but I don't know what they currently implement/provide.
was just merged w/ . I'll try building chromium w/ the flag - as you say it takes a while, so I can leave it overnight and give it a shot.
how does the situation look like with ? Is the flag available there, as in, screensharing with wayland already works there?
yes, it's available in google-chrome. ! I'm still trying to get it to work with xlr-desktop-portal-wlr - I've done this in the past, but it's not working out of the box yet with
And just to make sure, you also did set as described there?
yes I did. I'm almost got it working I think. There are a few issues out of the box: -chrome is missing the pipewire 0.2 runtime dependency, so I it as (I'm on 20.03 so pkgs.pipewire is 0.2): .pipewire service doesn't work - it doesn't seem to be setting up the path correctly. I'm trying to fix this now: My current config on 20.03 looks like: Where is the same package that was recently merged.


yeah, I'm currently already looking at it - pipewire wants to execute , but it's not in . We can patch to contain the absolute path. I'll check if it works and will get back to you.
Btw, we /really/ need a sway NixOS test, and better documentation on how to use sway. I was trying stuff until it worked, and does autologin me into a sway, but there might be a smarter way to do this, without also starting X.
The sway recommendation is to just run sway from the terminal after login - that's how I do it at least. I was able to workaround the environment issue by doing (but this is a kludge I think and shouldn't be necessary). But unfortunately it's now crashing and I'm not sure why:
Yeah, even my sddm config I also had to , otherwise pipewire complained about not being able to reach dbus: Afterwards, it segfaulted, as it wasn't able to find ; I patched to be able to find the path to , and that error message is gone. Now (apart from not being able to find bluez or rtkit) it /might/ only be some version incompatibilities, not sure: I'll see if I can get as far with your chromium PR, will merge that then, and also submit the pipewire patch.
Okay, with the pipewire patch and , It seems I'm able to share at least my own application window :tada:. I don't know yet why the alacritty window nearby isn't shown, and why "Entire Screen" is black, but that's probably due to me running sway inside X via ssdm.
pipewire PRs:
I don't think you're using pipewire in that case. xdg-desktop-portal-wlr only supports full screen sharing atm. If it is black that means it's not working. By the way I had to add pipewire02 to my system packages to prevent xdg-desktop-portal from crashing. But now there seems to be some incompatibility in the pipewire service logs when chrome tries to connect:
you should be able to cherry-pick the to not have to manually add this to $PATH.
Thanks! I'm suspecting google-chrome is compiled with a too old version of pipewire.


Enabling pipewire debug logs, it seems to be sending an incompatible format to the pipewire server (similar to ). I have got this working with chromium compiled against pipewire 0.2.7 in the past, so I'm pretty sure it should work assuming the client library is recent enough. Once the chromium package has that flag enabled I'll try to retest.
I just confirmed my last comment by building chromium locally w/ rtcusepipewire=true. It works perfectly for fullscreen sharing.
Hmm take that back - it worked the first time but not anymore :/. Not sure what lib is missing where.
Seems like xdg-desktop-portal is crashing:
This might be yet another version incompatibility problem. I propose merging (as it's built with 0.2 everywhere else too), and then see if we can get it to work if the system pipewire also is 0.2. I asked upstream about these problems in - maybe 0.3 needs to support 0.2 clients for some time until we should switch.
Heads-up: the bad client situation should have been fixed with the latest pipewire release, PR at
Thanks for your help! I'm still getting the xdg-desktop-portal crash, however. I'm guessing there is something missing from my dbus environment - or perhaps it's trying to access a file/directory not available in nixos.
could you open a new issue with some more details, like logs etc.?
Okay, I made


Freenet installs successfully but fails to run for both the service and the package with Steps to reproduce the behavior: Failure with Or alternatively with the service = true; to config For Freenet to start and be able to access setup wizard on 127.0.0.1:8888 Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


On today's master () - and probably others - building the attribute of many package produces an output that differs from the output on another architecture. Nix will display a hash mismatch. I tried with x8664-linux and aarch64-linux. Execute this on aarch64 and x8664. The aarch64 build produces the below output while x8664 is happy with the hash in nixpkgs. Please run and paste the results. system: host os: multi-user?: sandbox: version: nixpkgs: and system: host os: multi-user?: sandbox: version: channels(root): channels(andi): nixpkgs:
x8664 build produces same output for me: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I noticed something similar on macOS in Could some recent change have caused this? Perhaps ?
I reverted in a branch on my fork. My x86_64-linux laptop doesn't complain about the hash sum - as before. The aarch64-linux community box also doesn't complain anymore. Can anyone else confirm this?
I just made a diff of : The left side is aarch64, the right side is x86_64. Both are done on the same git revision ().
What a weird behavior that is missing.
Probably related:
I think this may be related: I also see different hashes on NixOS 19.03 vs. stable. I use the branch, but when CI builds the derivation on 19.03, the hashes do not match. If I build on NixOS 19.03 with from master, the hashes do match. This is quite annoying, because it makes it impossible to have package sets that work on NixOS stable and unstable without using rustPlatform from a nixpkgs newer than 19.03. I'll try to revert and see if I get the same hashes on 19.03 and master.
That's indeed it. When I revert , I get the same as 19.03. Maybe this change should be reverted? Since NixOS is not a rolling distribution and people run both stable and unstable, it would really be nice if package sets and overlays work on both versions. This also makes backporting changes easier.


Diff between the vendored dependencies: Here the differences also seem to be missing dotfiles (e.g. and ). I think this is the upstream PR that changed this behavior: (Edit: oops, I just saw that already mentioned the associated commit.)
is a critical update and reverting it will break multiple Rust packages. Rather I think we should get that change pushed into the channel, and then update any Rust packages whose changes as a result.
The only bummer is that it also breaks people's own packages on the channel as well.
Yeah, it would be bad to break people's derivations as an update to a stable release. At any rate, the 19.09 release notes should probably have a blurb that points out that hashes will change due to changes, so that people who update from 19.03 to 19.09 are prepared. There are probably also derivations in that have incorrect hashes now, since the file that is generated by is now excluded vendored dependencies.
I’ve updated the title of the issue to better reflect what I think we now know. Additionally, I’ve opened to update the hashes for all packages that haven’t been updated in master yet. I would appreciate a review on it. Once that’s merged, I can do the same thing for the affected release branch.
Looks like I misunderstood and this hasn’t made its was into a release branch yet, so we’re almost done here. Somebody just needs to add the release note for 19.09.
with the changelog PR () being merged, is there anything else missing?
Don't think so. :) Somebody can shout if I'm wrong.


Describe the bug The new version of Agda is working fine on other systems, but not NixOS. I've reported a bit more about what is known at To Reproduce Steps to reproduce the behavior: Agda 2.6.1 any file (e.g, ) Expected behavior Agda checks the file quickly and exits. Additional context Issue in the Agda repository: agda/agda Metadata Maintainer information:
I believe that this is fixed by rework of our Agda setup ! (Which is included in the most recent nixos-unstable.) Can you confirm? :-) $ echo module Main where && time agda Checking Main (). real 0m0.132s user 0m0.104s sys 0m0.028s Looks reasonable!
I haven't had chance to test the new stuff, but this issue probably should be closed anyway, as it's being worked on upstream (). I'm doing fine now using the workaround of adding option .


Project description A Python-3 (CPython = 3.9.0) Interpreter written in Rust Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
I tried to package it here: but run into compilation failure:
Rustpython master builds just fine. PR in


Describe the bug I encountered this bug when trying to use that does FFI. The particular call in general was the equivalent dlopen on the libc library and resolving to the system one which would cause a SIGSEGV. Digging into the source some more, you discover that Java sets a default value for if it's not explicitly set. Adding system libraries (i.e. /usr/lib) breaks/invalidates the hermetic invariant needed by Nix. These library paths are also searched first before those set in the DTRUNPATH of the ELF header as documented. I suggest the OVERRIDELIBPATH is either set to empty string maybe or even the contents of the ELF RUNPATH header itself. To Reproduce I was using JRuby which makes it easy to reproduce by using a gem which ultimately calls the JNR FFI. (The following reproduction results in the SIGSEGGV) Expected behavior Expected behavior is for the FFI call to work! This can be resolved by setting to the correct lib. NOTE: I could not merely set LDLIBRARYPATH because that would apply to everything in my nix-shell. Furthermore, wrapping java is somewhat tedious, seemed pragmatic for now. Notify maintainers Metadata Maintainer information: All JDK derivations
If you are curious for the JNR call that loads the C library:
OVERRIDELIBPATH is not sufficient, because it still SYSEXTDIR/lib, which is somewhere in . We'll need a patch. This also means we might as well write C code to get the right rpath value, even when . Although less useful, I'd be ok with a patch that just makes it . At least that will give a somewhat useful error message instead of a crash. ~It seems like OVERRIDELIBPATH was designed for cases like ours. Setting it to a static rpath value is tricky because that way we're duplicating it in a way that can't be later. It a statically known value. So I'd go with the empty value.~
I'm hoping (haven't tested) that with an empty OVERRIDELIBPATH the DTRUNPATH at least will be searched for. Do you want to work on this change together ?


I don't have a lot of experience yet with the JDK derivation (8.nix etc..)
I don't have a lot of experience with that either, but I do implement RubberDuck and I'm happy to review Nix+Java ecosystem stuff.
Tagging who seems to do a lot of JVM Java work as well.
Reopening: more versions to be done
I marked this as stale due to inactivity. →
[x] OpenJDK 8: [x] OpenJDK 11: [ ] OpenJDK 17
why does openjdk 17 not have a mr?
Do you have a specific problem? With the example above I could not reproduce the jvm crash.
sorry, i thought i was hitting this bug, but turns out that the bug i hit is different
Is there a way to reproduce this issue for openjdk17? Otherwise I'd propose to close the issue.
Afaict, it has not been written yet. You may not have the "right" libraries in to make it crash. I don't think we need a reproducer. We know that the unpatched behavior is bad, and it is highly unlikely that upstream's behavior changes, because the rest of the world depends on it. did you have a specific reason not to patch OpenJDK 17? Could you patch it?
That patch does not seem to be too complicated. I could prepare it, but I'd feel better if I had some use case to test if the patch is working.
I mostly just forgot about it sadly. Some other stuff picked up and it kind of fell by the wayside sorry about that. On Thu, Jul 28, 2022, 2:19 AM Benjamin Asbach
Closing since it looks like the last bit of this was fixed by . Happy to reopen if I'm mistaken.


Data that was once config and recorded on doesn't get updated when the configuration changes. This is a violation of purity. And more than that, it's very surprising when trying to install, hesitating between pgsql and sqlite, and struggling before understanding that the configuration doesn't get used anyway :p cc
that's a bit tough. We have a unit, that's supposed to do the installation. We use the command to install nextcloud (passing the configured database and adminpass settings as command parameters). This CLI generates , and installs nextcloud. The script checks the presence of , and skips installation on following starts. If you now change configuration from the module, we won't run the install command again, as the config file already exists, and assumes nextcloud is already installed.
Hmm… Maybe it would be possible to generate the somewhere in the store, and symlink to it? This way the next time runs it can in addition check whether points to the correct store path. Now, I don't really know what exactly does, so maybe it's not actually possible to do this because eg. one would need to re-run on certain configuration changes? In which case it'd be hard :/ but at least we can maybe make fail or something like that, so that the issue is at least noisy?
I don't recommend to do this, I just tried that (after upgrading one of my personal systems) and this tries to recreate a database schema which can end in very bad results. Unfortunately I doubt that this will work properly, nextcloud wants to merge this during the runtime. E.g. it adds a after a successful or adds trusted domains when running the corresponding command. I'm using this as well now and hitting these issues, unfortunately I don't have useful ideas either ATM, but I'm happy to discuss better solutions :)
Nextcloud edits it's in a lot of different places, so having it generated through Nix currently isn't possible. digs into that already, I a comments about our use case here too.
to avoid other people running into the reconfiguration issue for now, what about documenting that, maybe in ?
That's certainly a good thing to do.


If nobody else wants to take over, I'd volunteer to do this during the next week as investing time on improving the nextcloud module is one item on my todo list :) I was aware of being stateful, but thanks a lot for linking the corresponding ticket! I'll have a look at this as soon as I have sufficient time to :)
In the light of this issue, what's the correct way to upgrade nextcloud to a new major version? Do I just pull a newer , upgrade my system and hope that the systemd job will do the right thing?
The service runs an that should apply all changes like database migrations needed for the new Nextcloud version (beware, downgrades aren't possible). As long as you let Nextcloud do its job, you shouldn't get that much issues. IMHO the actual problem here is the configuration of the software within Nix(OS).
just a simple question (could not come to a conclusion after the lengthy thread) but I recently updated my nextcloud via nixops deploy and the update disabled the calendar module. Did I mess up or is that expected ? any way to configure this from nix ?
Assuming that you installed the calendar module via the UI, it is installed in . The beginning of my config reads: So in principle nextcloud can edit the apps installed via the web interface (otherwise you couldn't install them via the interface in the first place).
I don't think there's anything actionable here - the nextcloud nixos module is limited by how Nextcloud (imperatively) manages its configuration. The current state is properly documented in , and we raised our concerns to upstream in - closing this issue, feel free to reopen if there's more to be done.
I think one actionable item would be to have the nextcloud service fail with an explicit error if the configuration being used is not compatible with the configuration defined in the .nix. At least the user would be warned in practice that configuration is not really applied, and not only by the manual that they are relatively unlikely to actually read. Reopening for now, feel free to reclose if you think that's not a reasonable “solution” :)
The problem is we don't know whether the configuration on disk containing database connection information () differs from the one that would be generated through an installation via - we don't render the configuration on our own, but the installer writes it out as a side-effect.


If I'm not missing something obvious, checking configuration changes would translate to parsing/evaluating on every nextcloud startup as an , comparing every "interesting" key with the one provided through nixos configuration, and eventually then bailing out if they differ. I'm not sure if that's a road we'd like to go and keep up to date, while the underlying bug is a missing distinction between configuration and state upstream…
Since upstream mixes state and config it's questionable whether their configuration format is somehow supposed to be backwards-compatible (as it's only supposed to be used internally by Nextcloud). Hence I'm afraid that this will make i.e. upgrades even harder in case of configuration changes, so :-1: from me. As the issues are documented in the manual now, folks are warned and I think that this is a better option in contrast to adding more complexity to . I suggest we either close this for the reasons already stated or wait for an appropriate upstream fix.
I really don't feel good having stuff in that's actually a disguised command line… :/ Something that would sound nicer to me would be an executable that the user would have to manually run, and a bare-bones module that does not handle setup or configuration and just makes sure that the systemd unit is setup. At least the error is obvious (enabling the module without having run the executable would fail), all module options actually mean something, and the impure operation is made explicit. Either that or, similar to , rename all the options so it's explicit that they're used only for initial configuration. Would one of these solutions make sense to you?
Me neither, but currently we don't have much choice… I really like the fact that we can set up the Nextcloud instance in an unattended fashion, without having to worry about manual setting things up. I really don't want to end with more imperative setup steps than necessary. In theory, we could move some of the options in to to make it more obvious what isn't applied continuously. But TBH, I'd rather like to see the state/config mixing fixed upstream than having to introduce more mental complexity here, especially if this gets fixed and we end up with both incarnations. Really, this issue only occurs while a user changes nextcloud database parameters (mostly while tweaking his initial setup), and not having read the module documentation, where the behaviour is documented.


What about adding the following (subtile) log statement, to point users to the docs when they peek into the logs while things are not working as expected?
I agree that the log statement is the minimum we can do, and would at least give a hint about the way in which things are broken. Now, I guess the reason we're kind of disagreeing on the path forward is that you're much more hopeful than me that nextcloud will ever fix its stuff -- I'm assuming it'll get fixed in years at best (and even then…) -- and if it's in years then I'd much rather live with for years then spend a year deprecating it by making it conflict with new options than try to live with from now on and have users fail to understand what is going on. Now urhm, I'm investigating the module a bit deeper, and… is there any reason we can't put the database configuration etc. in ? We could then refresh on each activation, and it should be enough? If we have a way to couple it with something that automatically runs iff the database is not ready yet then the setup would actually be… almost perfect?
After having a deeper look at the sources ( at github, (6 commits ahead of v16.0.0RC1)) I guess that this should be possible (I didn't test it yet though). Configs will be loaded from using PHP's function[1] while all files ending with will be taken into account. Hence works as all config arrays will be merged together. This config will be loaded at [2] and is available as which is then used in the DI container[3]. If I understand the code correctly, I assume that it should be possible to render all config options in as config files found by glob will override values from [4]. [4]
Nice catch! This might indeed be possible - we should make very sure that config overrides work the way we think they will - seems to write the merged configuration, and not just the overrides (and merging this with other config in the wrong order can lead to wonderfully weird to debug issues) ;-) While I'd still prefer nextcloud splitting config and state properly, and being able to cope with read-only (base) config - it might be a direction worth exploring. What do you think?


Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)


Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --CC
I don't have time to look at this right now, but if anyone could run git bisect that would be helpful.
Likely caused by the libgpiod update in
If so, maybe we should bring back libgpiod 1.x for openocd?
How many users does it even have? Might be a good idea to do the same thing that is done for ffmpeg and llvm, i.e. separate libgpiod1 and libgpiod2 packages.


, CVSSv3=9.8 (nixos-21.05) The package glances before 3.2.1 are vulnerable to XML External Entity (XXE) Injection via the use of Fault to parse untrusted XML data, which is known to be vulnerable to XML attacks. Scanned versions: nixos-21.05: . Cc Cc Cc
This was resolved by


Describe the bug Putting a valid certificate name in will cause nixos-rebuild to fail. To Reproduce Steps to reproduce the behavior: this line in . This command will fail. Expected behavior finishes sucessfully. Additional context This error message is related to : I guess this error is caused by switching to python 3. 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:
isn't compatible with Python 3, it seems. We'll need to update or carry a patch.
MRTC:


Today one of my containers wouldn't start after I updated the docker-compose file and it was due to the docker engine being too old to support a certain feature. Easy enough to fix in config but is there a specific reason the attribute points at rather than ? Last time the attr was touched was
The reason is basically this: Quoting a recent comment in that PR:


Building with (on nixpkgs unstable) leads to I found identical issue from 2019 in RedHat. They claim this patch fixes the issue, however I haven't tested this. (Mainly because I don't know how) I'd be happy to try to fix this, looks like just adding that patch will do the trick, but I'm new to nixpkgs Notify maintainers Metadata Please run and paste the result. Maintainer information:
The patch works. I'll submit a PR.
Is this different from ? Is the patch superfluous?
Oh I didn't see that, if that fixes it then this should probably be closed. The redhat issue makes me think that it is an issue with allegro so perhaps it should be merged anyhow to ensure it doesn't crop up later. But I don't really mind
I'm not sure that it should be closed just yet. I'd need to try building at the latest master without it. I did also run into the same problem you had.
I'm pretty sure this is fixed now


If you serve files from , nginx will set last-modified header to unix timestamp 1. The result is that browser will cache indefinitely. Not sure what we should do about it really, following nginx configuration helps:
Why do you need to turn etag off?
Ah, I see. nginx's etags aren't hashes.
I wonder if we could find a way to pull the hash out of the nix store path and put it into an etag header.
Thanks for finding this. I've been having issues with broken caching on my nginx/nixos server. Even when the files on the server were updated (files in the nix store), the browser was told that no change had happened. If I'm understanding this correctly, since nginx's etags are based on filesystem modification time; you can't have proper cache invalidation (ie. it will always send 304 not modified). Or is there a workaround?
+1 this is a problem. And turning off etag seems like overkill. Is there some way to 1) set the date on a file so that Nginx can pick it up, or 2) do something else awesome?
Is the zero-timestamp rule set in stone in Nix, or is there some way to override it if you really want a file in /nix/store to have a particular timestamp?
I think we could get away with: It's not perfect, as it will change on each Nix evaluation instead of being content addressed. Another way would be to turn the store path passed to nginx directive to translate into an etag.
The etag function is at called from and . Making it dependent on the realpath of the file seems doable.
Explanation how to configure nginx to use the hash from the nix path:
In my testing, this sends the correct etag, but does not send the 304 not modified, when the etag matches. Also, the header gets stripped out when compression is enabled.
It's working perfectly for me. I've gzip compression enabled, the etag header is sent and the browser gets a 304 when querying the header.
Nice! An example with a directory would be more common:
I've to correct what I said. your statement seems to be correct. What happens in my case is that Cloudflare is actually handling the caching of the ETag correctly, not nginx.


So this approach is completely useless without external caching. I'll investigate further and see if I can come up with a solution.
Here is a patch: If real path (after dereferencing symlinks) of is in Nix store, it will use path's hash as ETag. For example: I'll take some time to double check everything and only then send a PR. However, feel free to test: nix { pkgs, ... }: { = { enable = true; package = with pkgs; nginx.overrideAttrs (super: { patches = (super.patches or []) ++ [(fetchpatch { url = ; sha256 = "16pa1vwcm7kibkjsxpk3szaa2vnxdinml6v0fp4038i2qaav113k"; })]; }); }; }
This is really great! or anyone, do you have a moment to write an explanation of this new feature and its practical ramifications for anyone configuring an nginx server? Since it isn't typical nginx behavior, I think the nixos manual should explain it somewhere so it doesn't catch people by surprise.
I think is a good explanation, just needs to be put into the manual.
Cool, submitted .


Package name: bottles Latest released version: 51.11 <!-- Search your package here: --- Current version on the unstable channel: 51.9 Current version on the stable/release channel: 51.9 <!-- 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! --- Old/incorrect PR Notify maintainers (for last modified) <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


ChefDK is deprecated and no longer maintained by Chef. This package is currently maintained by and I believe ChefDK should be dropped and replaced by Chef Workstation (see issue ). This has been deprecated since 2021.


Build of failed on x86_64-linux as of . Maintainer cc: Other cc: n/a nixpkgs at commit This issue was automatically generated by . that created this issue. Internal tag:


According to the 3.5 life-cycle () , the final release has already occurred and is now considered EOL. The jump from 3.5 to 3.6 has already happened in the majority of python packages and should not be a similar situation in which we had to extend python2's life long after its official EOL date.


Steps to reproduce the behavior: python311Packages.pymatting Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


python-kasa recently updated to 0.6.x from 0.5.x. The home-assistant project does not yet support 0.6.x, as a result kasa functionality is degraded. Using HomeAsisstant from latest nixpkgs, attempt to get emeter data from kasa devices. I reported this issue upstream and they advised on the version issue. There are more logs visible there. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I guess that if we would run the unit tests then the issue with 0.6.0 would have been detected.


All ceph tests are currently broken on release-21.11 and master. First broken in ( to ), likely due to a snappy update, like ). Steps to reproduce the behavior: -build -A etc. Tests should complete. Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:


Fetchers are hard to test because when the output sha is verified, Nix won't download it again. This leads to confusion and PRs that are effectively untested because the others do not realize that they need to remove the store path before testing. Examples: Steps to reproduce the behavior: a fetcher -build the fetcher -build "success" but the fetcher is broken a PR effort The fetcher runs every time. This is expected but not realistic, because Nix can not guess what to re-fetch. Instead, we can make fetcher testing easier by adding fetcher tests following the pattern: So this uses IFD which is probably ok for ofborg? Regarding ; instead of somewhere, we'll have to use to set on the fetchers because they're functions. The salt may need to be passed externally in case of pure evaluation. We could make it a Nixpkgs parameter that defaults to . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Maintainer information:
Workaround: Use followed by
Or we can just put the salt in the parameter. Nix isn't clever enough to find same-hash renames in the store :)
And the salt can be derived from the unsalted drv path, which is exactly what we want. See


When using ffsend from nixpkgs, after uploading a file, the program segfaults. Using Nix on macOS with an M1 chip, but also tested it in a NixOS VM (arm64). Don't know if it works on x86. Steps to reproduce the behavior: The link to the file should be shown. Using the version from homebrew on macOS works. It even works when compiling it from source using cargo through nixpkgs (on macOS): only changed the version last time and last edit was four years ago Please run and paste the result. macOS: NixOS:
What version of rustc are you using to compile ffsend outside of nix?
I'm not familiar with Rust, I just ran in the ffsend git directory and it "just worked" so whichever version is currently in nixpkgs (at least on macOS). I haven't installed Rust on my machine.
Thanks, I have performed a bisection on nixpkgs and the regression was introduced in , so I just wanted to check that it could work with the latest rustc


Project description awatcher is a window watcher designed to be used in combination with Activitywatch, an open-source time tracker that is already in nixpkgs. Activitywatch needs a window watcher program running to get info on what programs are open and for how long. nixpkgs already includes the default window watcher (aw-watcher-window) and the WIP wayland version (aw-watcher-window-wayland), but awatcher supports both X11 and Wayland, while featuring better Wayland support than aw-watcher-window-wayland. This would allow using Activitywatch in combination with KDE or Gnome on Wayland or when running Hyprland. Metadata homepage URL: source URL: license: Mozilla Public License 2.0 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


A recent update on unstable broke compatibility between OneDriveGui and OneDrive client. Steps to reproduce the behavior: unstable to current version ( ) a OneDrive profile configured in OneDriveGui OneDriveGui window OneDriveGui correctly recognizing the cli client ! After some investigation on their respective repos, it appears that OneDriveGui 1.0.3 is not compatible with OneDrive 2.5.x, now in rc (and in Nixos unstable) so this is going to stay broken until OneDriveGui releases their 1.1.0 version. There's an open issue on their repository... which points to an alpha release of the new gui... it might be of interest to package that one on unstable. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
FYI , v2.5.0 will GA 16th September 2024 AEST


Describe the bug When running the Mixxx package it fails to open and prints: Steps to reproduce the behaviour: 1) Run 3) Run from the command line. Expected behavior Mixxx opens its GUI Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
this needs a fix in
Can confirm running for example on my machine works.
Does not fix this for me. I've created: which does


Describe the bug causes Lego to fail. To Reproduce Steps to reproduce the behavior: set on an enabled certificate. to this configuration. fail. Lego complains about an unrecognized (really misplaced) flag. Expected behavior The certificate will be successfully fetched, with Must-Staple enabled. Screenshots Additional context I think the problematic code is here: should not be in commonOpts, it should instead be in runOpts and renewOpts. Lego runs successfully when is to and . Notify maintainers (the acme team) Metadata Maintainer information:
Thanks for the report :) It appears that the --must-staple option is common to both "run" and "renew" modes, but is not actually a common option that can be specified before the mode. I'll get a PR ready for this.


Steps to reproduce the behavior: system configuration with Freetube in it. See and for the exact same issue with Morgen. Electron version lock seems to have been introduced with . Upstream seems to be at Electron 27: . and
Maybe we could add the patches from It looks like they were waiting for a nixos user to test it and eventually gave up on us.
are you able to test ?
Looks good as far as I can tell.
fails on this branch, for whatever reason.


does not start on the Mac. Steps to reproduce the behavior: via symlink, sandbox violation the app into the Application folder, sandbox violation 1Password should start Please run and paste the result.
I should have noted, that also doesn't work
Did it work prior to the update? Regardless, I cannot offer help with the Darwin side of things, I only use 1password-gui on NixOS.
that I can't say for sure


Related to Project description Jitsi Meet desktop application powered by Electron Metadata homepage URL: source URL: license: Apache-2.0 platforms: unix, linux, darwin,
+1 as the App seems to have some benefits over using just a browser. Whoever starts working on this, please remember to deactivate the auto-update functionality.
Also I would suggest to make sure we are using a recent version of Electron and nodejs, as don in this fork:
There was a 2.0.0 release two days ago: I think this fixes the outdated dependencies issue mentioned in the previous comment.
Yes a pull request from the fork I mentioned before was accepted.
I fixed the outstanding issues and PR is ready for review


When building chromium with args like this and the gn args aren't known/accepted by chromium (like the above one actually is that is still given incorrectly in 18.03), it will print: but continue to build anyway, which can be super surprising when your build doesn't do what you expect. We should catch that when building. Unfortunately doesn't seem to have a feature to warn. But we can run to see the in stdout and grep for it: I have confirmed that only seems to work that way when giving a build target, like . CC
Suggestion: We switch to
PR
pull request was merged.


Describe the bug I'm trying to use NixOS in a UPS client (not server). When , the and services shouldn't be running. There is a note that says that is not used currently. To Reproduce Steps to reproduce the behavior: Error: and fail. Expected behavior only upsmon should be running Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Maintainer information: See also
Looks like there's a pretty simple workaround:
I marked this as stale due to inactivity. →


Describe the bug The following snippet: results in services failing to start due to missing config files etc. : : ( fails too, but that could be down to the fact that I haven't plugged the UPS in yet -- but for the record, it complains ) Expected behavior I'd expect the services to start successfully (and probably complain about the missing actual UPS). Notify maintainers (The UPS module appears to have received only drive-by changes for the last several years, so no idea who to bug personally). Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
OK, should've read the whole module: I'm supposed to supply the missing /etc/nut files myself because it's unwise to keep them in the store (they could contain passwords and whatnot, I guess?). Declaring (in the service definitions) the state directory to be but creating for the purpose appears to be a real bug, though :)
Also (sorry for the semi-off-topic) what are best practices for referencing hand-written config files without their contents winding up in the store? Double-symlinking? If this is documented somewhere, then I haven't found where.
I was struggling with the same problem as until I noticed this bug report. After copying and editing , , and from to (and setting on all those files), I was able to get it to work. I think this should be more discoverable. If it's not appropriate to copy those sample files to on the users behalf, there should at least be detailed instructions on the option to explain what else needs to be done.
I marked this as stale due to inactivity. →
Agreed this should be more discoverable. Perhaps at least could be defaulted to empty and written, since I seem to be getting away without anything in there. In case it helps anyone, I got it working with something like this:
I was hit this bug today, too. Maybe we can fix it by using a startup unit that handles the secrets and setup the state directories like nextcloud or syncthing do
Been working on today and wanted to put some notes here. Using version 2.7.4. First, isn't used by for PIDs and it will try to write to .


flags , , may be needed instead of environment variables until a 2.7.5 release. Ref: Using for debug makes it non-forking, requiring a change to the systemd unit . I was able to get to run as non-root: I'm still working on understanding how to manage state directories in NixOS but this was needed:
I set out to get my UPS (cyberpower CP1500 AVR UPS) working with NixOS today. This was the first issue I came across, I figured this was the best place to share my configuration. I probably made this more complex than it needed to be because I have no idea what I am doing, and it is definitely not secure; one problem at a time.
Not stale; still relevant
Thanks for providing your standalone config! I learned a ton tweaking it into a netserver config! The below config creates a working NUT netserver that other machines on your local network can be connected to. The only thing I have yet to figure out is a secure way to include passwords in .nix files that won't show up if I push my local copy to github. Any ideas? If you want to tweak when NUT shuts down your computers you can modify the values of " = <percentage" and " = <seconds" under "directives". SHUTDOWNCMD will be triggered when both conditions are met. The "ignorelb" directive is necessary to have NUT ignore the UPS's defaults. Anyone using this config may want to make sure SHUTDOWNCMD and NOTIFYCMD point to the correct binaries in their filesystem. One other thing of note is to check the value of the "schedulerRules" field under below. You must give it the path to your file. I just put a copy of it inside my /etc/nixos. Could probably add another variable to hold the path for convenience. `
For secrets in nix config, I think the current recommendation is to put it in a separate file and not include it in the repo. See also
I have been using sops-nix to commit encrypted passwords to my NixOS repo, but I have yet to put in the elbow grease to make this work with my upsmon password.
is my attempt at making generate the config files necessary for basic operation. If you are using , could you try out the changes and leave a review?


Using the latest packages from the unstable channel I am unable to enable the default virsh network. The error indicates an issue with the firewall backend, but I disabled the firewall systemwide through: = false; What am I missing here? system: host os: multi-user?: sandbox: version: channels(root): channels(tim): nixpkgs:
Have you looked into libvirtd logs for a better characterization of the issue ?
Yes but I could not find anything meaninful, but I'll continue trying to find something
I'm seeing this the 2019-12-19 04:34:37.251+0000: 4078: error : virFileReadAll:1431 : Failed to open file '/sys/class/net/virbr0-nic/operstate': No such file or directory 2019-12-19 04:34:37.251+0000: 4078: error : virNetDevGetLinkInfo:2460 : unable to read: /sys/class/net/virbr0-nic/operstate: No such file or directory Also, I noticed that ebtables was updated recently.
I'm facing the same issue. I have the nixos firewall enabled, and it complains it can't find ebtables. If I install it separately that error goes away but I still see the errors posted by above
I confirmed that reverting ebtables to 2.0.10-4 fixes this. Not sure what the next step is.
Idea: set EBTABLES_PATH=/sbin/ebtables-legacy in libvirt config.
When bumped from 2.0.10-4 to 2.0.11, the binary was renamed to , so the configure script fails to find it at build time.
Impure workaround for the desperate: add the package to , and symlink to . (I also tried from the package, which does not seem to work.)
Another workaround for less desperate: in your overlay.
I verified that providing an to the right binary in the derivation allows my VMs to work again. I tested in a overlay I maintain, from which a minimal (untested) extract to work around the issue until someone has time to come up with a more correct patch to submit upstream is:
I've confirmed that the overlay in works.
I also have the issue.


This is actually a major issue, if libvirt does not work anymore.
Had the same issue with unstable. The overlay above fixed it. Do we just need a PR to staging-next that adds that environment variable to the build? I'll submit that PR if that is all that is necessary -- didn't see any submitted yet.


nix-shell -p supercollider [anders $ nixos-version (Flounder) [anders $ nix-env --version nix-env (Nix) 1.11.2 [anders $ nix-instantiate --eval '<nixpkgs' -A lib.nixpkgsVersion ""
you use supercollider ?
no, sorry.
Same here:


Steps to reproduce the behavior: nomachine-client Seems like nomachine changed their tar file. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems that NoMachine has removed the from their website and the link is now a redirect to the homepage. The new latest version is .
? this url works


fails while compiling The same thing happens with Steps to reproduce the behavior: or: is successfully installed. Here is the output:
Fix in
Thanks On the same system that I encountered the error on, I checkout out the branch with your fix and then ran: The installation worked and is runnable. I'll be doing more testing later today/tomorrow.


Package name: mythtv Latest released version: 34.0 Current version on the unstable channel: 32.0 Current version on the stable/release channel: 32.0 Notify maintainers Announcement: Changelog: Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description Youtube client in terminal for music ( lightweight youtube client ) Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux, darwin


Package name: nix23 Latest released version: 2.3.17 (see ) Current version on the unstable channel: 2.3.16 Current version on the stable/release channel: 2.3.16 Notify maintainers Note for maintainers: Please tag this issue in your PR. See for context. The release script apparently doesn't upload source tarballs anymore, so 2.3.17 sources look more like the other ones. There's a bunch of expressions in that might need to be revisited.


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


The current process for renames puts out-of-tree modules in a situation where users are confronted with warnings they can't solve, and neither can the maintainers. Steps to reproduce the behavior: one change, create the new option/package/..., create the alias with a deprecation warning that goes into effect immediately -of-tree modules, such as home-manager, nix-darwin, start emitting warnings reports warning -of-tree module maintainer can't do anything, because stable release does not have the new option All generated warnings can be resolved by the user. Suggested process: one change, create the new option/package/... and the alias but no deprecation warning 1-7 months pass. All current branches now support the new way. enable the warning on master (more on that) -of-tree modules, such as home-manager, nix-darwin, start emitting warnings warnings can now be fixed To facilitate the process, we can add an argument to functions like to indicate the first release that will support the change. We'll maintain two (hidden?) version numbers that we update during the NixOS release process. For example, at the time of writing, the only supported stable version is 21.11 and 22.05 has not been released yet. To enable warnings on , we only need to update . Interestingly, we'll be deprecating functions that deprecate without . Sounds meta, but it's not complicated. It just means that some old style deprecations will slip through the net for some more time. (also a big one, but no complaints yet)
This is also related to NixOS/rfcs, which was a previous attempt at establishing general such deprecation behaviors


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


Steps to reproduce the behavior: unar from Full build: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result.
This could be related to GNUstep being updated??
Yes, that PR is the cause.
Ouch, sorry. Could've sworn I ran nixpkgs-review against it, but maybe I didn't. I'll try to see what I can do, although maybe only next week. We can also revert, if I can't find the time or nobody else comes up with a fix.
For the status on Hydra:


Project description Granian is a Rust HTTP server for Python ASGI/WSGI/RSGI applications. It fulfills a similar purpose as daphne, gunicorn, uvicorn or uwsgi, but . Metadata homepage URL: source URL: license: bsd3 platforms: unix Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


shows this for me: When I try to upgrade my system, I get the error “could not find any previously installed systemd-boot”. This is because the script can't deal with systemd-boot versions with a minor version appended to it, since the regex is : Fixing this is not quite straightforward sadly, since the version is later used for comparison, so fixing this requires adding support for proper major/minor version comparison in this script. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --??? Please run and paste the result. Maintainer information:
related


Despite the bintools for riscv64-linux advertises the existence of , it is actually missing. Steps to reproduce the behavior: , returns the output, there is only , no the same process for , is both advertised and available. Either evaluates to , or is available in <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Looking at ;a=blob;;h=;hb=HEAD is not supported on riscv64. tracks it upstream. I don't expect progress implementing the support any time soon.
Then we should accept the second solution: mark as false, we should also double check the availability of gold on other ELF platforms.


Project description Python app to work with pictures and associated metadata from Apple Photos on macOS. Also includes a package to provide programmatic access to the Photos library, pictures, and metadata. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This was the most complex package i ever tried to write :sweat_smile:


, CVSSv3=7.5 (nixos-unstable) CVSSv3=5.3 (nixos-unstable) CVSSv3=5.3 (nixos-unstable) In InvoicePlane 1.5.11 a misconfigured web server allows unauthenticated directory listing and file download. Allowing an attacker to directory traversal and download files suppose to be private without authentication. In InvoicePlane 1.5.11, the upload feature discloses the full path of the file upload directory. InvoicePlane 1.5.11 doesn't have any rate-limiting for password reset and the reset token is generated using a weak mechanism that is predictable. Scanned versions: nixos-unstable: . Cc


Describe the bug fcitx-qt5 fails to build on unstable: To Reproduce Metadata nixos unstable
It's trying to install into qtbase . Probably should set this to be within the proper prefix.
yep I've seen that as well. Seems like some packages set to work around this but haven't had the time to test it yet. EDIT: that fixed the first problem but not the second one:
will fix this.
This is still an issue on stable -- Installing: /nix/store/phkl5sfpn4jvncjd2sa29g182gpmmja7-fcitx-qt5-1.2.3/share/locale/zhCN/LCMESSAGES/fcitx- -- Installing: /nix/store/phkl5sfpn4jvncjd2sa29g182gpmmja7-fcitx-qt5-1.2.3/share/locale/zhTW/LCMESSAGES/fcitx- -- Installing: /nix/store/g83143pyn6sc1x1nqqjcamap4c2b1rbw-qtbase-5.12.0-bin/lib/qt- CMake Error at (file): file INSTALL cannot copy file "" to "/nix/store/g83143pyn6sc1x1nqqjcamap4c2b1rbw-qtbase-5.12.0-bin/lib/qt-".


Call Stack (most recent call first): (include) make: * [Makefile:106: install] Error 1 builder for '/nix/store/ypfmrmajq452nmskg0ffwa27hm58l492-fcitx-qt5-' failed with exit code 2 cannot build derivation '/nix/store/hdsvn6hc7h7wf29kdnpvr7iaivplyyb8-fcitx-with-plugins-': 1 dependencies couldn't be built cannot build derivation '/nix/store/4lwxfbacn5fcymlm3jpv6wl4anllxmzd-system-': 1 dependencies couldn't be built cannot build derivation '/nix/store/d4k8dywj47xrbxfmvdaw4gywnwdn874r-xsession-': 1 dependencies couldn't be built cannot build derivation '/nix/store/fj8xinm3fjd7sp9s20iqg23yx27zc193-nixos-system-voyagertwo-': 1 dependencies couldn't be built error: build of '/nix/store/fj8xinm3fjd7sp9s20iqg23yx27zc193-nixos-system-voyagertwo-' failed Note that I have a following setting in environment.extraOutputsToInstall = ["out"]; environment.pathsToLink = [ "/share/locale" ];
:confused: Didn't expect that to broken the same way on stable. please open a separate issue requesting some sort of backport for the relevant commit
Still seems to fail on unstable?


, (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) (nixos-19.09, nixos-unstable) Scanned versions: nixos-19.09: ; nixos-unstable: . May contain false positives.
On it
Done


Describe the bug build of OpenEXR fails to find -lImath24 To Reproduce Expected behavior Successful build. Screenshots Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: Maintainer information:
Something seems to be mangling the library names incorrectly? The ilmbase package contains: Notice the periods.
cc.
I lack the hardware to debug this. any ideas?
Repro'd on 10.14
seems to indicate that autoconf-based builds are only supported on linux - we may want to switch this to cmake. Building outside of nix via cmake is working fine for me.
can you give a try?
I can confirm this still builds on at least.
appears to fix this for me (macos 10.14). Reopen if it's still a problem for you.


While deploying a machine via deploy-rs, I had this error: Then stop docker or deploy the service from scratch, my belief is that docker-prune can start before docker.service and thus fail since it can't access the docker daemon. No systemd error whatever the configuration. I believe a patch like this should fix it but I am no systemd expert: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- from blame current unstable
I think the patch you propose makes sense. Could you open an PR for it?


Building RStudio fails with the following error message (seems to be something to do with the fact that QMake got upgraded): Run . System: (NixOS: , Ubuntu/Fedora: , ...) . Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )


It's interesting that this doesn't happen on (x86_64-)linux, apparently.


Project description Yet Another way to use Windows VST plugins on Linux. Yabridge seamlessly supports using both 32-bit and 64-bit Windows VST2 and VST3 plugins in a 64-bit Linux VST host as if they were native VST2 and VST3 plugins, with optional support for plugin groups to enable inter-plugin communication for VST2 plugins and quick startup times. Its modern concurrent architecture and focus on transparency allows yabridge to be both fast and highly compatible, while also staying easy to debug and maintain. If I understand correctly, this provides similar functionality to the airwave package. I think the big plus to this package though is that it emulates as if they were native which means the build process doesn't need to require the user to go to the steinberg site and download the VST SDK (as airwave currently does). I used this on Arch with Reaper and it was extremely easy to get going. I had a much easier time using yabridge than trying to get carla set up and running. There are multiple AUR packages for installing from source or just pulling in the binaries. I've tried to package this myself but it's just a bit beyond my means. I think that if someone is more familiar with packaging wine related binaries or compiling with meson from source this would be a quick win. homepage URL: source URL: license: GPL 3.0 platforms: linux
I probably won't have time today, but I can take a look at this later. I'm pretty familiar with the nixpkgs wine build, and I've worked with the ZynAddSubFx build to add support for the Zyn-Fusion ui.
Amazing. I was able to take your PR and get Upright Piano working with Reaper as well. Thank you so much for the quick turn around, I really appreciate it.
Hi! I don't use NixOS myself, but if it helps, there's one person in the yabridge Discord currently using yabridge's master branch with NixOS. And I've also ran into another Nix build definition on GitHub in the past (but that one's pretty outdated by now).
I've just released with a lot of important new features, fixes and improvements including the first ever Linux <-Windows VST3 plugin bridge.


I saw that the package created by for yabridge 2.2.1 has not been merged yet, but please let me know if you want to update the yabridge and yabridgectl packages for yabridge 3.0.0 and need any help! One additional dependency is now a patched version of the VST3 SDK which is patched to compile under winegcc and with support for Meson. I'm not quite sure how Nix packaging handles those things.
Thanks, I have it building right now. I'm just testing out vst3 plugins right now :smile:
:cry: For some reason neither the vst2 or vst3 plugins are working, even though they get synced. I think it might be an issue with my system installed wine. I'll submit my changes anyway so other people can test it out.
So they are found but yabridge fails to load them? Which Wine are your derivations using?
You can try running manually to see if that is the issue. A plain call should print: And should print:
I'm able to sync them with yabridgectl, but they fail to load in Reaper. I'm using (currently version 6.0) to build yabridge, but I have a custom build of wine staging 6.0 currently installed. seems to be working fine:
That indeed seems to work as expected, that's great news! If you start REAPER with and then take a look at after trying to scan/load a plugin then you'll probably be able to figure out what's wrong very quickly.
Hmm, apparently the path to the VST host is too long :stuckouttongue:
Huh I can't think of from the top of my head what would be throwing such an exception. That message printed after comes from a try-catch around the entire plugin startup that catches and prints any . Windows (and thus Wine, because it has to be compatible haha) has a path name limit of 255 characters, but none of those paths sound like they should come close to that.
Yeah, sorry. It was just a problem with my home environment. I was trying to test it without installing because I lost the nixpkgs commit I used to generate my home-manager environment.


REAPER was just loading the old 2.2.1 yabridge- :woman_facepalming: I just finished rebuilding my home environment with a new nixpkgs commit, and it's working now :smile: .


Currently, our Android SDK derivations contain only binary files. This is unfortunate during development, when one wants to jump to a definition of a particular symbol in the SDK and it is not found. For comparison, ArchLinux is doing this in their packages, e.g. System: 16.09pre-git (Flounder) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "16.09beta335." /cc
Created PR .


Describe the bug Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(hyper): channels(root): nixpkgs: Maintainer information:
I've also encountered this. I bisected it to . says there's a newer version (1.) whose release notes say "Fix two test failures on newer versions of gtk+/gnome-shell/mutter". However, updating to it does not fix this test failure. :( With 1., the exact failure I'm getting is:
When updating to GNOME 3.34 I did indeed notice this and tried the exact things did. We probably need to report it so it can be fixed, I just didn't have the time to do this. Guess the testsuite could be disabled.
Disabling tests got it to build for me. I'll try to find some time to open a PR for that, and to report it upstream.
Reported upstream:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .


Describe the bug Keyboard backlight keys don't work out of the box on LXQT. Pressing one brings up a polkit dialog for authorization to run as superuser. Of course, changing the backlight brightness should not require authorization. liblxqt provides an function in which I believe is the problematic code path. This function calls a helper utility as follows: FILE lxqtbacklightbackendgetwritestream() { FILE stream = popen("pkexec lxqt-backlightbackend --stdin", "w"); return stream; } There is a polkit rule for this: $ cat <?xml version="1.0" encoding="UTF-8"?<!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" ""<policyconfig<action id=""<messageAuthentication is required to Change Brightness</message<iconnamebattery</iconname<defaults<allowanyno</allowany<allowinactiveno</allowinactive<allowactiveyes</allowactive</defaults<annotate key=""${CMAKEINSTALLPREFIX}/bin/lxqt-backlightbackend</annotate</action</policyconfigHowever, this rule ends up expanding to e.g.: <annotate key=""/nix/store/k1w634ib02dxqh046icm2i7ml28iycq5-liblxqt-0.17.0/bin/lxqt-backlightbackend</annotateand polkit is presumably just finding the binary in . It appears that pkexec doesn't resolve symlinks, as if I run on the path, I get the prompt, whereas if I run on the resolved path, I don't get prompted, and I can adjust the brightness from the command line. I'm not sure what the proper solution is here. I don't know enough about polkit to have an opinion on its symlink handling. Maybe we can provide another polkit rule for the path? To Reproduce Steps to reproduce the behavior: LXQT and boot into it. a display brightness key on your keyboard. polkit dialog appear. Expected behavior Display brightness should be adjustable without entering your password. Screenshots If applicable, add screenshots to help explain your problem. Additional context I'm running NixOS 20.09, and have hit this bug both with the shipped LXQT, as well as when I backported 0.17.0 from .


Notify maintainers Hi there thanks for providing an update to 0.17 so quickly! Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(khumba): nixpkgs: Maintainer information:


LLVM 12 (not yet released, currently at RC3) will be required for building Chromium M90+ (currently in the beta channel; stable release planned for 2021-04-13; s. ). cc I couldn't find a draft PR for LLVM 12 yet. Are you already working on it or currently busy? LLVM Release Schedule: 12.0.0: Jan 26: release/12.x branch, 12.0.0-rc1 Feb 23: 12.0.0-rc2 Mar 2: 12.0.0-final
I have't started yet. But I think I have a few minutes now!
Just a heads-up, we have Should that transition to ?
I have to hand this over to you, Borg says the unit tests fail (on both platforms, consistently). Maybe the testing framework needs a bump?
Actually, LLVM is not enough I tested with and the key commit seems not included into You have to either wait for compile LLVM now cherry-pick to or related
The match is a bit out of context: We have so everything should be fine. ok, thanks for that information! If I understand that correctly you've tried compiling or with and it requires cherry-picking as well (which would be unfortunate because that commit might not be part of the final release; they don't seem to have a dedicated branch for the LLVM 12 release and I don't know where/how/if they track and provide that information - Edit: Oh, they have a branch (the GitHub UI doesn't seem show all branches that a commit is part of) but wasn't cherry-picked so far).
I built (from llvm master, simple replacing with fetchFromGitHub and removing some lines in ) and it builds Chromium 91
RC3 in


Upstream , but we still have many packages depending on it. I know of no issues since the last release, so I'm not marking it as vulnerable yet, but the dependents would better start migrating in advance. Stable: it's unclear to me what we do about these in 19.09, but perhaps there won't be any notable vulnerabilities before 19.09 support ends :-) 1.0.2 is the default in 19.03, but we don't support that anymore.
List of files:
I think we should mark it vulnerable. Other EOL packages have been marked vulnerable because of the EOL before, e.g. Firefox, and if there’s any package we should be extra-careful with, its OpenSSL.
I bumped it to fix the last CVE minutes before opening this ticket, so I was obviously biased against marking it immediately ;-)
BTW, it's still a decision to make, as there's surely some LTS distro that will keep shipping 1.0.2 for some time, so patching the worst probably won't be too difficult. I'm personally not willing to invest significant time into it, though :-)
Best way to motivate somebody to volunteer is to mark it as insecure. ;)
OK, I think the we've given enough time and now we should press on a bit:


Package name: surrealist Latest released version: 2.0.1 <!-- Search your package here: --- Current version on the unstable channel: 1.11.7 Current version on the stable/release channel: - <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --NOTE Surrealist has now officially moved to the SurrealDB Github org, see Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Nvm the nix package is actually built from source, just Tauri builds a deb in that process
Working on it. I'm currently stuck at an issue with the frontend build. There is a transitive dependency to that does not get installed by pnpm.


Project description <!-- Describe the project a little: --Sunshine has already been packaged here in nixpkgs: But it doesn't come out of the box just by , according to and and , at least it needs a and maybe . It would be better if we could add a NixOS module for it to make it availale just by sth. like or . CC maintainer Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This has been on my to-do list for ages :) The module itself wouldn't be a huge deal, and I think I have a plan for tests, just need some time to work on it.
I actually started working on this a while ago. My module can create valid and files (i.e. they work when I start sunshine manually) and open the necessary ports, however I couldn't get the systemd service to function properly. If I recall correctly, the issue was related to getting access to the screen. Here is what I have so far, maybe it can help someone:
Thanks I used yours as inspiration and opened for this. It's still a draft -- I need to work on the tests -- but any testing or comments are welcome. I've tested on Plasma 6 + Wayland + AMD and seems to work, have not tested much with Xorg or NVIDIA.
Think it's got all the functionality I had planned -- marked as ready for review.


c.f. If using --patterns-from, all of the paths to back up are (or can be) read from the pattern file, and specifying paths on the command line is optional. But the nixos configuration won't let you omit the paths, and since they aren't stored in a variable you can't even do something awkward with preHook or preCreate to unset them.
While investigating this, I found the related issue that since it requires "paths" rather than "strings" it also only works for absolute paths; if you want to back up relative paths (using preHook to make sure they're relative to the right directory) this is impossible. Not sure if that's worth opening a separate issue for.
I changed it to .
Thank you!


Package name: podman-tui Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 0.18.0 Current version on the stable/release channel: 0.12.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --I attempted to update this package myself and create a PR, however, there appears to be a major changes to how this package is built that are outside my ability to address. Attempting to build the package after a , both with and without the changes in , results in the following build log: Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


XRootD failed to access the files following the URL, complaining that isn't found and the authentication handler couldn't be loaded. However, does present in the output directory. Steps to reproduce the behavior: Enter the top directory of Nixpkgs See Run See the detailed output A clear and concise description of what you expected to happen. If applicable, add screenshots to help explain your problem. Terminal output during execution: Short: Long: is packaged by myself, but I haven't found the solution. Suggestions and helps are more than welcom. Please run and paste the result.
This is probably because has the wrong . How to fix that though? No idea.


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


Project description Unity is changing the way they deliver the editor via the UnityHub. They have shifted away from the appimage and have started Debian and RHEL repositories. They are not producing the appimage anymore. Would it be possible to add the new UnityHub to NixOS? The new download instructions are here:
Extracting the binary from the .deb is fairly simple and has been done in similar situations in nixpkgs before.
Is there any quick fix to use unity right now?
Not that I have found. You could use an old version of the appimage if you still have one. The flatpak is available but is a really old version.
I am currently building a derivation locally to extract the binary from the .deb package and make it run. Lets see how long it takes
have you had any success? I have but it yells about and crashes when I try to use it
I thought that unityhub is an electron app. My current attempt results in a f mismatch from electron. Here is my . I build it via .
Yeah it is electron but I'm just trying to package the prepackaged electron binary instead of using system electron
Yes you are right. When trying to use the included electron binary it will result in the same error. Hm when I have some time I will investigate with . Or maybe you had any luck?
Unfortunately not, I've seen one other mention of the same error with electron with no solution, and I'm not sure how to do deeper debugging personally.
I've managed to do something: by adding to LDLIBRARYPATH, I can get it to not , but now instead it just hangs... I'll keep trying but I'm not sure what it is this time.
I've made a tad more progress, I forgot to enable gnome-keychain so that was causing the hang, but now it's segfaulting :sweat: I do see it looking for but I'm not sure what that even is
Finally, got it working. It boots up and I can install everything properly. The remaining issue is that hub-installed versions of Unity aren't patched so the hub fails to launch them. It seems that since the previous version used appimages, the library paths were passed to the editor as well as the hub, but I'm not sure how to do it with this. Do I need ?


I'll try that but I'm not sure if there's a more optimal solution.
Looking at the code seems to be the way. !
<details open<summaryWeird error I'm getting when I'm trying to open say Preferences or the Package Manager in the unity editor.... I have no idea what this is from, am I missing gtk stuff?</summary<br</details
Hopefully the final bit of the saga, it turns out the GTK issue I had isn't unique to NixOS, it occurs on other distros too, see the . In that case, it seems my derivation for the updated Unity Hub is working properly in all other regards, and can be found . All the need to be cleaned up, I may have a few unnecessary ones, and there's a lot of leftover testing with the QML paths :sweat_smile:. If it looks good, perhaps we can update Unity Hub in nixpkgs too? I've also made a describing how to use Rider with Unity on NixOS as well, might help someone out.
Thanks for that looking forward to seeing that on master!
Hehe thanks for the reminder, forgot to make a PR for updating the package!
I just copied your derivation meanwhile and was the only thing it make unity work (installing the 2021.3.4), thanks!
Hello I use Unity and just tried out file. It works great! However, I cannot find your PR. Would you be able to point me in the right direction? I would love to see this in nixpkgs soon!
I've been kinda busy recently with other prs and such, but I'm definitely planning to make a PR in nixpkgs, if not later today, definitely by this weekend. Thanks for the support :)