lists a listener option called that can be used to listen for incoming network connections only on the specified interface. Unfortunately does not accept this option. Steps to reproduce the behavior: This should evaluate cleanly. Incidentally, that assertion message drops the component in the attribute path, it might be nice to fix that.


I started grafana-agent in flow mode, and tried to access the http API at http://localhost:. Unfortunately, instead of providing a web interface to debug the current list of components, I get a "404 page not found". Steps to reproduce the behavior: grafana-agent in flow mode. port via HTTP I'd expect grafana-agent to ship with the web interface. Please run and paste the result.
It looks like is what's building the frontend. Unfortunately, the web interface seems managed by yarn (and has a ), so we'd need to first provide a . I tried to have resolve the dependency, but it seems it's not able to:
I manually patched things in to bump to a more recent version, compatible with the react version that's mentioned in , but ugh, I'm not really sure why it's that way. I'll ask upstream.
yeah, sorry, I don't use flow mode (yet?) and the nixos module does not support it either, as far as I am aware. I can try looking into it as well, first, before you raise an issue upstream. While the nixos module might lack support for it (for now?), I believe we should try fix it nonetheless :)
Yeah, we should probably have a second NixOS module for flow mode, it's very different and the existing config structure doesn't make much sense - for now I just did ship my own custom systemd unit for it: But yeah, without the web ui it's quite annoying to debug, so we should probably get that sorted out first, before providing a module and getting more people to use it.
fyi
I tried to move it over, but still seems to be terribly slow when trying to resolve deps and not being able to, so I guess we should stay with yarn.
We should prefer yarn simply due to upstream having an instead of a :) ^


The packages and are outdated () and have been replaced by the package (). To update a derivation just replace those two packages by as a build input. The following packages depend on and/or : [x] openmpi (fixed in ) [x] (does not find librdmacm in the configure phase when compiled against rdma-core) [x] (infiniband support seems to be defunct. configure does not check for IB libs and it is not linked against any of the required libs, libibverbs or librdmacm) [x] (RDMA support was removed from )


Steps to reproduce the behavior: localstack (from unstable) (version 3.2.0) localstack 2.3.0 works and so does (tagged because you bumped the version) (the channel is slightly messed up. I am using 23.11 but with flakes) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The new version requires too many dependencies to package up in a reasonable time frame and even includes circular ones. contains a revert to 3.0.0 which builds for me and shows the usage. Can you take a look if that works for you?
Sorry for the delay! Yes, the revert works well for me! Thank you!


ember-cli nodePackage The command line utility. If someone could give us some pointers we might actually have a crack at it ourselves ... Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin


Package name: mongodb-compass Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 1.43.0 Current version on the stable/release channel: 1.43.2 <!-- 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]:


Describe the bug For some reason neither of nix-env, nix-build or nix-shell compile Lean standard library, i.e. there are no .olean files. This results in abysmal performance even on trivial code, because every time it needs to recompile entire library in memory. Also, there is no leanstatic.a installed. To Reproduce Steps to reproduce the behavior: Expected behavior There should be compiled .olean files. Additional context Building Lean manually using compiles standard_library by default without issues. Also, there was no such issue on older NixOS. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Turned out that compiling standard_lib was included in tests. Adding should fix the issue.
Except that 39 tests have failed :disappointed:
This patch fixes all remaining issues, which proves that in NixOS 20.09 expression for Lean is broken:


Describe the bug I'm unsure what the error is, but it seems to relate to ulauncher being unable to find the project path, whatever that may be. To Reproduce Steps to reproduce the behavior: Expected behavior For Ulauncher to start normally Additional context This is the error message I get: Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(miyuki): nixpkgs: Maintainer information:
See the PR linked above. The issue is that the ulauncher package must be installed via , , , or something similar. Using does not work (for reasons explained in the patch). The PR both updates ulauncher and adds a note to explain what's going on to Nix users trying out the package. I think it would be a good idea to create a NixOS module for Ulauncher. I might be able to do this after I finish exams in a couple weeks.
Alright guys, the real solution here is to just use rofi. With a little work you can make it look pretty good and with a little extra work one could easily make it look similar to ulauncher. Here is my config I tried to fix this issue up but it seemed to work for maintainers thus it was the end of that story
Hello ulauncher package maintainer here. This definitely shouldn't be the end of the story. I do want to get these issues fixed. The problem is that ulauncher wants to store paths to its assets in a config file within . Typically we'd just let it use paths for everything, but that would cause ulauncher to break if we update the derivation then garbage-collect the old paths in . I also use Rofi right now, and it works. But I really want the plugin ecosystem of Ulauncher, so I'm motivated to fix this situation. Perhaps we could modify the current package to allow decoratively specifying the file contents (like ), which would allow the package to be used without messing with system state? Maybe we could even create something like and a NixOS module?
Perhaps this is a good fit for a home-manager module?


In any case, this issue can probably be closed once is merged. Maybe a new issue should be opened to track the addition of an unlauncher module?
I marked this as stale due to inactivity. →
bad bot
I installed (rev ) through . Unfortunately, I get this error message on launch anyway.
same issue here


Describe the bug Doesn't build. To Reproduce Steps to reproduce the behavior: Expected behavior Screenshots Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


Describe the bug qtwebengine fails just after successfully configuring with error message To Reproduce ` Expected behavior should compile Notify maintainers Metadata
Pull request works on my machine. Thx.


Project description Enables common unix utlities like cut, awk, wc, head to work correctly with csv data containing delimiters and newlines Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin


Buck as installed via nix reports with an older release version than the one listed in its nixpkgs My guess is that is probably the correct version. The issue here is that IIRC buck Expected behavior 's output should match the version rerefenced in the build file. Notify maintainers
I did try to investigate by bumping buck to its latest release that should be Python3 compatible but didn't get very far as I am unfamiliar with the build system. But maybe the patch helps With this I encountered a failure at the end of the build
buck now generates a hash for build outputs


Package name: pulsar Latest released version: 1.117.0 Current version on the unstable channel: 1.114.0 Current version on the stable/release channel: 1.117.0 Notify maintainers


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:


This tracks the conversion of from DocBook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.


This tracks the conversion of from Docbook to CommonMark per . here that you intend to work on this. (Please also post if you stop working on this.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections in the NixOS and Nixpkgs manual for inspiration. the CommonMark back to DocBook xml with: from nixpkgs root dir with: a preview server with: your work at on steps 5-9. it looks good, commit both the new file and the generated file, submit a PR and reference this issue.
I opened a PR for and : PTAL, thanks in advance for reviewing :-)


Project description Ente's 2FA app. An end-to-end encrypted, cross platform and free app for storing your 2FA codes with cloud backups. Works offline. You can even use it without signing up for an account if you don't want the cloud backups or multi-device sync. Metadata homepage URL: source URL: license: AGPL-3.0 license platforms: linux, windows, android, ios, apple silicon macOS, web Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Describe the bug has , preventing it from being used on other platforms, particularly Darwin in my case. To Reproduce nix-shell to get this error: error: Package ‘postgis-2.5.2’ in is not supported on ‘x8664-darwin’, refusing to evaluate. Expected behavior Produce a postgresql-and-plugins package with postgis available. Additional context Simply allowing doesn't work immediately because PostGIS' build system is quirky. There was some relevant-looking discussion on . Metadata system: host os: multi-user?: sandbox: version: channels(lukeworth): nixpkgs:


Describe the bug Mailman module in NixOS requires postfix enabled and has no way to configure Mailman to work with other MTAs supported by both NixOS and mailman upstream. To Reproduce Steps to reproduce the behavior: postfix mailman the evaluation with an assertion Expected behavior The Mailman module allows to select an MTA of choice (or even adapts to the currently enabled MTA) Screenshots n/a Additional context Notify maintainers cc Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(vika): nixpkgs: Maintainer information:
It looks like exim's configuration should be RFC42-ised first if we want to inject Mailman-related settings into Exim config, which is a requirement (Mailman requires a custom Exim router and transport).
Yes, the module is currently quite opinionated. If you're willing to contribute exim support that's great.
I see how I could make it work, but the first version of it will require manual editing of Exim's config files (because RFC42-ising Exim will be a pain, even though I have some drafts on how to translate Nix into the syntax that's required), and I'm not sure if it will be merge-worthy enough :3
Exim config is complicated enough as is, I'm not sure adding an intermediate layer from nix will help that much. I also don't really see this integrating well with existing or other exim config. I'm honestly kind of surprised this works for postfix.


Project description As discussed in is now EOL and the dev's have moved their effort to . As per the in order for it to work specific need to be set up. We can probably do something similar to what we do for the expression: Metadata homepage URL: source URL: license: GPL3 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
For people who subscribed to this issue: I opened to add streamcontroller


Yes. We have a package which is what I tried, but since it’s a thin wrapper around it’s possible that it’s still not built with the right options. Also I’ve noticed these messages from : does not show the extension, and GLX applications fail to start. Originally posted by in I probably merged , too early. I'm not totally sure this is working properly.
This is pretty much a help wanted because I lack the depth of knowledge and hardware to help anymore with Nvidia things. My goal with finishing was that it could be possible and improved upon. i.e packages are built with the capability etc.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
The last few evenings, I have tinkered around a bit. I was not successful so far. Here are my findings: I have set the following options: This page says that there is no acceleration support for xwayland and nvidia yet but glxgears fails to start, so I think this is another issue There are multiple versions of : One from the egl-wayland package, the other from nvidia-x11 package. As the one in is loaded, I tried to replace it with the one from egl-wayland. Though, the result is the same with both. When starting an application, which would use acceleration, I can observe this line in the kernel log: Using , I can see that is accessed, though one of the calls fails: one more thing: looking at , gnome-shell is listed. Maybe it has working acceleration? Edit: Got a bit further: Found a reference to an additional directory, which is used to look up libraries: Creating a file in there: with the file in /run/opengl-driver/lib/libnvidia-egl- being replaced by the one from egl-wayland package. Now the error in xwayland is just a warning: I can run a wayland native terminal, but still fails If you have any suggestions, what to try next, I would be glad to give it a try.
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant.


This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
I'm trying to get this working as well. However I can't even get the session chooser in GDM in 20.09. Is it only working in unstable? Any tips? Here's my config
With this overlay and the 470.42.01 driver, nvidia is usable with xwayland. :tada: , unigene-valley and so far every game I started on Steam. Only issues I have so far are that chrome does not start properly Workaround is to start it with some options: and in CSGO there is noticeable input delay.
I've updated to the latest nixos-unstable () which includes updated & , but I'm still facing issues. While it's generally working I have problems with some apps. : : : Additionally in my system logs I can see: & are both working. My relevant config: I also tried using an overlay to apply the new meson flags from overlay: Is there anything else I need to set up?
also fails with
I have a very similar setup as and am experiencing precisely the same errors. I'm not sure whether it's an issue with gnome, my particular config, or what. Things work fine when running in an X session.
:thinking: I don't see anything missing with your config . I have updated my config to and removed the overlay. and are producing the same errors, and chrome won't function properly unless started with and are working for me, as well as and and . Note: Seam is installed via but this should only be relevant for running games inside steam, not steam itself.


I came here because I'm experiencing the same as and Can't launch Steam or Kitty under Wayland: nvidia: 470.42.01 xwayland: 21.1.2 Config is virtually identical to
I found this issue because I had the same problem as After reading , I tried to create a different file (listed in the end). And that solved my problem. With this file, I can open steam. However, alacritty still has an error. Maybe that relates to another . The cause of this problem is that even though both and packages provide , cannot be found without a json file. The says: So, maybe we should add a json file /usr/share/egl/eglexternalplatform.d /xxx.jsonnvidia-x11egl-waylandlibnvidia-egl-wayland.solibnvidia-egl-, gnome setting says my video card is "Unknown". In the end, I will post my related config:
I filed this issue to see if we can patch to look in the right place: If we can't get it to look in then we should probably just add the etc symlink in the nixos module so that this works correctly for end users out of the box. I'll send an initial PR shortly and will update it in that egl-wayland issue gets a useful answer (or if there's another way to patch a closed source SO that I'm not thinking of).
BTW, I can confirm the different results. When I override nvidia's with our "upstream" one, I get more info in , but I'm not sure if there are other functional differences. Not sure what I would've expected, but it nags me that there's a difference.
PR:
Interesting, there IS a way to override the egl_externaplatform search path(s):
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
would this still be an issue after ?
I think it needs and
I am taking over as I've been using that setup as a daily driver and have a rough working understanding of the pieces fitting together. And to confirm, the general problem here, that is addressed in , is EGLStreams working in Wayland environment with the NVIDIA driver (aka, it doesn't now because we don't "wire up" NVIDIA's egl driver per egl-wayland's expectations).


That is pretty tangential to NVIDIA having a driver that supports GBM allocation and "wiring it up" (an extra piece included in ), and it being discoverable (whatever I send to replace ). Hope that helps.
Also, to reiterate, is good to merge independently on it's own and will resolve this issue. Separately, a replacement for will be necessary for the ideal Sway scenario without users having to set an extra env var.
I thought the point of the new Nvidia driver was to finally move away from EGLStreams? Is EGLStreams used by the new stable driver at all?
I don't know? It doesn't really matter, we should still fix it? Like, the fundamental issue is that we're simply not installing the Nvidia driver correctly for NixOS when it comes to these important configuration JSON files. Plus, it's not like everything is going to immediately switch to GBM, drop EGL, know about the env var, on and on. That, and the wiring for GBM is in that PR and I'm not splitting them apart at the current merge rate.


, CVSSv3=6.5 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc
I couldn't get the vulnerability to compile and run, so I don't know for sure whether this version bump is actually a fix. Nonetheless, here's a PR.


Describe the bug Build fails when trying to install . I get: To Reproduce Expected behavior The package should install without error. Metadata Maintainer information:
cc
Related to
Tried the following: It doesn't even bother about the C-core Version 6 that I asked: What am I doing wrong ?
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 .
Refreshed. My PR will fix this issue. Thanks for your patience.


Describe the bug is currently in nixpkgs master. It was released in July 2018. was released in October 2019. It contains a few improvements and may also contains fix for some vulnerabilities: Is there a reason to keep the old version in nixpkgs, other than a lack of manpower? I'd be happy to do this work, but I just want to be sure that I was not starting a long, difficult and redundant work. I already tried a "naive" bump of the and but it does not work, mostly because most of the patchs are not valid anymore.
This was solved by cc.
Thank you for continuing this work!


Project description ET: Legacy is an open source project based on the code of Wolfenstein: Enemy Territory which was released in 2010 under the terms of the GPLv3 license. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin
I got a derivation to work: This is for the 32-bit build, client only. Run and use the binary. Planning to properly package it and contribute to nixpkgs, but since it's my first package it'll require some more time. Also planning to get the server and omnibot working.
I marked this as stale due to inactivity. →
Still interested.
My version of derivation gist doesn't seem to work now that I've upgraded to NixOS 22.05. Haven't had time to investigate too much yet. Whether I try to join an online game server or host a game, I get the below error:
This adaptation of gist is working for me. It's currently for the 32-bit Linux version only, so produces a package . There is an option to use the mod libs built by the ET Legacy project (CI pipeline) or compile them locally.
Hi guys Based on gist I did compiled using NixOS VM Machine it runs fine but there a small quirks there Date is not set correctly it is set to beginning of the time :D Also does ignores manually set env variables ?
Added those 2 in etlegacy*.nix files ` Those 2 should fix issue with correct compile date and naming scheme to build non package But it does not Am I doing something wrong ? :D
Package created and pull request created. Just waiting on PR to be approved so the package can be to nixpkgs.
Is it normal I cannot find the package in the unstable channel?
I think there may be some delay as it migrates to the unstable channel, and then into 23.05.
it seems to be in unstable now.


fails to install on . It worked before the recent update. It fails early on in the check phase. I'm guessing the fact that I have to build it from source at all is because it also fails everywhere else, so there's no cached build to download. Try to install on system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Hmm, the tests worked just fine for me on
Do they work for you now? What's kinda weird is that I never get an error message or anything. You see in the output I posted above, there's just loads of dots. It kind of sits there printing dots for a while and then it looks like it just times out or something.
For what it's worth if I put in the derivation, the resulting player is perfectly functional at least for my purposes. Haven't tested every feature or anything though.
I think it crashes during the test. I will try bisecting.
Bisecting was inconclusive because I ran out of resources when building webkitgtk.
What commands did you run? I have a server with plenty of resources that's just sitting idle at the moment, I could try run it on that.
but I guess it might make more sense to skip the builds where dependencies failed by running something like:
Cool, I've been running this for a while, for what it's worth it's currently narrowed it down to between and .
I'll let you know in the morning when it's finished.
The original bisect command I ran didn't take into account the case where dependencies failed to build, so I had to run it again with a script like the one you suggested. Here's the output of :
FWIW I managed to build it by setting in an overlay. Works for me, but I wouldn't suggest that this is done in the Hydra build of course!
Yeah, we should probably add in the expression if this still occurs.
I get quite a bit further, attempting to build rather than . The entire test suite finishes, then reports three test failures related to icons and GTK / GDK.
Seems like the tests are failing again
I marked this as stale due to inactivity. →
EDIT: Kindly ignore this comment, didn't notice that I was using the deprecated repository. Hi, I'm encountering the same errors as reported previously. In case anyone else is experiencing the same, I was able to fix them using:


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


segfaults on launch Game runs Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I noticed this as well yesterday running nixos-unstable


I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. →


Buck build system is packaged with the wrong JDK it seems PR introduced a bump in JDK version, see (). Metadata Please run and paste the result. Maintainer information:
I guess the most recent version should support java 11:
Until they make a stable release with those changes included, we will just use jdk8


A clear and concise description of what the bug is. Steps to reproduce the behavior: to or -build switch to install android-studio android-studio and open one project the right-top button to sign to Google will open a dialog show nothing happened android-studio can open the default browser and success to sign in google. ! 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.
This is the same problem as , which I'm experiencing. Clicking documentation links from within Android Studio does nothing other than showing a jumping icon of Firefox besides the cursor for a few seconds (on KDE Plasma, X11), while it's expected to open the page in Firefox.


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


The recent changes seem to make sage crash when it tries to run some code using openblas (I think). I installed the sage derivation from the latest github repository. In the sage interpreter, run the following sage crashes with the following message: Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(okideal): channels(root): nixpkgs:
Procedural: as it is , please specify the CPU model. Looks like the Sage build system had the idea to use somewhere… I.e. the local build could work. I wonder how feasible it is to find where Sage does it — the Sage derivation is allowed to rebuild a lot of dependencies because it is just too much pain to make it use the system versions.
Here is the output of lscpu
From the traceback it presumably crashes here: which is which indeed is an AMD-only instruction (MMX? thought that would be long obsolete by now...)
You were right. A local build works fine. Thanks for the help.
Thanks for your report. do we set to and give up?
This should be fixed by exporting (see ). I'm not quite ready to give up (even though it would probably be the healthier choice :grin:). I'm actually currently experimenting with doing it the "right way" and replacing the sage buildsytem with nix (with a mix of sage and system dependencies).
can you confirm that the latest binary works?
Sorry for the late answer. The binaries from the master branch seem to work. The initial crashes are gone and running gives only unrelated failures. Installing from still gives me the old, faulty binaries though.
Are you sure you updated the channel? What do you mean by "binaries from master"?
I meant that installing from the master branch of the git repository works. I was not aware that there is a difference between nixos-unstable and nixpkgs-unstable. The latter does not seem to include the fix yet. Installing from nixos-unstable works well. Thanks for your help.
Okay, I guess hydra is a bit overwhelmed by all the fixes for the upcoming release. Thanks for reporting.


Project description Unofficial source port for Blake Stone series (Aliens Of Gold and Planet Strike). Metadata homepage URL: source URL: license: mit platforms: linux


error while building using unstable channel trying to build a system using weston pkg building successfully I assume its an easy name swap changing "libseat" on 4th line to "seatd"


Describe the bug The uses the following source definition to build (in ): This source is no longer available, returning an HTP 302 redirect to a new homepage: Navigating the new home, this seems to be an alternative download location: However it seems to be a different file (warning, very slow download, file is ~ 140M in size): To Reproduce Steps to reproduce the behavior: -shell -p cups-kyodialog3 Expected behavior Packabe builds properly. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(marc): nixpkgs: Maintainer information:
I was slightly wrong because I don't understand how is supposed to work; it is the same file. The following works for me: I had to add the URL fragment to get to extract the file though.
does kyodialog3 works this way? Could you create a merge request?


Describe the bug From IRC: ; Looks like we currently just use their appimage: and our appimage tooling uses buildUserFHSEnv: It seems like we can either: using (build from source, maybe?) similar to how iohk patches Daedalus.
I tried packaging it with yarn2nix, but stumbled upon , unfortunately.
I don't know much about the appimage architecture. Why exactly can we not run appimages natively without FhsUserEnv? Is it just because binaries linking against fhs paths? In this case we probably could run autoPatchelfHook on the contents of the appimage and produce a new image that links against nix libs. EDIT: I just tried this. Extracted the appimage contents, patched all binaries, but then when executing ledger-live-desktop, I'm getting: Currently I'm running ledger live via qemu + usb device passthru via . That works fine.
how difficult would it be to lift Daedalus's patch and use it for the libudev inside the fhs? I've never worked with FHS before, but also don't want to build ledger live from source...
I tried to build ledger live from source and it didn't work because of the issue that mentioned. Patching libudev worked though.
can you link to the patch? It would be great to be able to use my more-trusted nixos machines for these types of activities.
I already created a PR for it and it's referenced above. This one:
Feel free to comment in the PR whether it actually works for you :)
The patch had to be re-done in Should this problem probably be communicated to upstream, so we can think about how to fix this long-term in a more sustainable fashion?


Describe the bug When booting with ZFS legacy mountpoints like this: the boot fails as described in this post: To Reproduce I guess this is difficult if not anyone is having this issue with legacy mountpoints, but it seems that in the linked discourse post, I'm not the only one with this issue. But I've tested it just on this commit: where it fails, and on this (just one commit before): And there everything works. Expected behavior Mounting of legacy ZFS mountpoints succeeds while booting. Notify maintainers <!-- Metadata Please run and paste the result. Maintainer information: --
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Can you check if this is fixed by ?
I tried with this overlay: Not sure if that's the way to do it, but it didn't work.
it should probably be
Thanks I tried that, and it didn't work. Not sure how to confirm the patch got applied properly though.
if you have the log output, you will have something like:
Guys, just to report, I'm in the latest zen with ZFS 2.0.1-1 with encryption, unstable channel and I'm not having any problems.
I've just found time to test this, thanks for the research. The patch did indeed fix the issue for me! (I've checked the log output for the application of the patch). For the sake of completeness the overlay I've applied (needed a slightly different sha256 sum for me):
Could you make a PR adding the patch to zfs?


A clear and concise description of what the bug is. The package doesn't include a folder. I am looking for a version of which includes the executable. Are we building the package incorrectly such that it doesn't include a binary? Any and all help/advice is much appreciated :bow: Steps to reproduce the behavior: output - notice there is no folder A clear and concise description of what you expected to happen. I want the executable. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- might know something about this? :man_shrugging:
was the binary there before On a quick note: I have never used , so I am not familiar with the package. It seems that the package also needs an update:
It appears that the binary requires AMPL, a commercial package, which is not packaged in nixpkgs. See: https://coin-
ah, I understand. Thank you.


We've had issues with building atom-beautify since This happens now in both Atom and Atom Beta channels. Error for Atom: Error for Atom Beta: Travis CI for your fork Travis CI or a Docker image for nix and checkout master from atom and atom-beta Last successful beta/stable build: https://travis- Last successful stable build: https://travis- Both failed: https://travis-
here is a new issue.
Seems to be related to
For stable maybe, beta is slightly different error.


The default boost version has been bumped from 1.69 (or 1.75) to 1.77. This is a notice for maintainers that the following packages are now failing to build: - - - - - - - - - - [x] cryfs A typical fix would involve pinning the package to a specific version (e.g. see )
My fix in is not the same as . Is there a very good reason to prefer one over the other ?
Well, I like trying to keep it away from the huge top-level file. (which is e.g. harder to use in git)
Re. pivx, I think we should mark it broken. Our current version is very old (and therefore useless), and the new version includes a rust build. I don't have the capacity to fix this ATM.
In my case, what broke it was the update from boost175 to boost177. Fix is in .
It's in the branch now, so please target any further fixes there as well (unless they're a mass rebuild, etc.)
colobot fixed with
FYI, ledger has some broken behavior with the new boost version, although it curiously doesn't cause a test failure: ledger/ledger.
Our expression does not attempt to run tests.
Ah, that would be why, thanks. Nevertheless, the binary exhibits the same problem described in that issue in interactive use.


Project description A cross-platform Discord Rich Presence integration for mpv with no external dependencies. (MPV Userscript) Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, windows
I've already but haven't PR'ed this to nixpkgs yet. Will probably do this when I get home from vacation next week.


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


Enabling services.hardware. (as a systemd service) breaks. Steps to reproduce the behavior: error about and several other errors like "has not been declared", "does not name a type", etc. To rebuild xow and everything else without any issues. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
The git not found problem is not fatal and the derivation overrides the version info anyway. Looks like another victim of our stdenv compiler upgrade. Looks like upstream master has a fix for that. Upstream is also orphaned so upgrading the derivation to an unstable revision is going to be needed in the short term and in the long term a replacement should probably be found. I don't have a working controller to test xow with any more so if someone wants to adopt the package, feel free to.


Steps to reproduce the behavior: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


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


rendered in : ! bumping osl to did not work. Applying did not work <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: nixpkgs:
I have verified that the problem exists with the current derivation even with version , which was updated away from in . I guess somehow the ZLIB_VERSION is replaced improperly , but I've got no idea what could be causing it, and I'm really confused why it's only become a problem recently, as it doesn't look like osl has been touched in either.
I've tracked it down to , and reverting it seems to fix it. I also believe it's a cmake issue. Consider this file Output: Maybe because the header changed to (? But if I'm reading the correctly, I think it should just set the version to an empty string? Either way, this patch seems to fix it I don't think it's worth raising with zlib because with the next patch version they're going to fix it anyway. It might be worth warning them in advance of 1.4. It's probably worth raising with cmake, because they will want to support all version, and then zlib won't have to care anymore either. I can open a PR for this tomorrow or when I have time, but don't wait for me if anybody wants to do it before.
Nice catch! One minor note: you are looking at 's master branch. It seems to be already fixed there as: We'll need that backport to . UPDATE: or wait for to reach master. With now is in .


Project description Converts Linux images and kernels into UEFI images. Metadata homepage URL: source URL: license: GPL3 platforms: Linux


In , I introduced support in libvirtd for UEFI VM creation. rightfully remarked that this brings closure-size up too much. Looking into OVMF shows that only 1MB out of the 114MB install size is needed to enable said UEFI VM creation. I think that we should look into splitting out OVMF_(CODE|VARS) from the rest package.


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


Possible, because X11/xkb/rules/*.lst [0] are somewhere 'hidden' in the /nix/store. [0]
Fixed, just let me do some updating on E19 libraries and I will make a pull request.


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


Easyeffects crashes when Echo Canceller is used (at least when applied on input). I've been told that it works fine on arch linux. Though it might be my hardware that somehow makes it crash. Steps to reproduce the behavior: Echo Canceller module to the Input Easy Effects to one of recording apps It doesn't crash It doesn't write anything useful in the logs, just exits with code 137. Please run and paste the result.
I can reproduce it but it is not a regular crash – there is not core dump. It appears to be killed. Weirdly when I run it with: The termination is not caught.
For me it reproduced with gdb: Maybe it's terminated when child process is crashed?
hmm, it seems to be something wrong with speex when configured to use the fftw library... not sure what, but this doesn't crash:
The same also happens in Speech Processor effect now:
Unfortunately this didn't seem to do the trick for me, it still crashes with the Echo Canceller.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I have the same problem. The thing is, used to work OK on my system. Then I tried the module, after which this issue appeared. However, now it's persisting. I undid the change, even tried booting into old generation, but is still getting killed with the echo canceller on. For reference, this is what I used to try to enable the echo cancel module (not sure if it ever worked):


Describe the bug Neo4j does not start because it cannot locate a Java Runtime. To Reproduce On my system, I installed with: Then, running shows: "The operation couldn’t be completed. Unable to locate a Java Runtime." Expected behavior Neo4j should start. Additional context Note that shows Note the line that sets to . Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Please run and paste the result. Maintainer information:


I just found out about wrapGAppsHook by examining a gnome package, but there really should be documentation about this in the Nixpkgs User Guide (a section about Gnome would be nice, which would show the right way to package GTK3 / GTK2 glib based apps). Also, perhaps there are other things I missed that one should know when packaging Gnome Applications or GTK3/2 apps? /cc Gnome maintainers
I'd like to know as well. Currently receiving this error: On one of the packages I'm trying to put into nixpkgs. Apparently sometimes you need for buildInputs. So apparently all you need to do to use this is:
The error occurs when you do not have any directory containing in variable. One of the things does is (which usually contains the aforementioned file) of dependencies to . (Actually this happens in cooperation with via variable.) Icon themes work in the same vein, only is used and it is populated by which is propagated to (). (XDG fallback theme) should be probably to any GTK application that uses icons (I think that is every GTK applicaton nowadays due to CSD) but some applications require Adwaita because they use icons not in hicolor. Not sure if this functions correctly though, at least it should not according to my mental model of how icon theme selection works; I will need to read the relevant XDG spec before I can finish the documentation.
Just thought I'd leave this comment here for future reference: if you get an error like for python gtk applications, try adding to propogatedBuildInputs!
It should go to , though. But be wary of


Many Emacs packages, for instance mu4e, move their -files into a subdirectory of . Nixpkgs currently only adds all files located in to the load-path but does not add the files in its subdirectories. This currently makes mu4e from Nixpkgs unusable (by default). We have to fix this snippet of code: E.g. will not make mu4e available within GNU Emacs.
I'll give it a try in a few minutes
Why can't somebody just fix mu4e instead of making emacs startup slower? Like make a wrapper for it like has for Agda or just put files into a correct place like package does? I see wanted to do this, but then changed its mind :(
This actually seems to be the default behavior for Emacs - at least for packages it ships with. See for an example or run to check the default value of (it includes subdirectories)
I see. Okay then. Still, personally I would prefer packages to separate their emacs things into a separate package or at least a separate output.
This broke the package which have subdirectories that include "non-public" files, which gets required as the wrong package for , etc. See Perhaps this should be revisited? I am not sure if this potentially breaks some other packages.
I have reverted this locally (or at least I think so, could be that the change was not propagated somehow), but still seems like paths are , I see a lot of projects test directories being to the e.t.c.
Here is an example of bad load-path and this is just a subset of them all, nix-shell to reproduce:


The derivation of creates a different .desktop file from the "official" one that has a different name. This is probably done in order to differentiate the two versions of in case someone installs both of them, but the problem is that while it creates a new one, it doesn't delete the "official" one. Also, the new .desktop file should also set , otherwise games don't launch in Wayland. (Though maybe it should be a wrapper instead) (And, unrelated, but why and not ?) The same also applies to PATH: there are both and (which is a link made by the derivation to in the folder). For consistency, there should be made a , otherwise if both dolphins are installed, one overwrites the other in PATH. Steps to reproduce the behavior: dolphinEmuMaster; an app launcher; are both the original "Dolphin Emulator" and the new "Dolphin Emulator (master)" that open the same app (the master one doesn't set `QTQPAPLATFORM=xcb). PATH there are both and (which is a link). There should only be the "Dolphin Emulator (master)" desktop file, and in PATH there should be only (and instead of ). <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --


Darling is a compatibility layer for running macOS apps on Linux (think Wine for macOS). I think it would be interesting to work on with macOS support. They have reverse engineered some headers that Apple doesn't release publicly so having them in "libdarling" could be useful.
We already have this part:
Just heard of Darling. I would be delighted if it could be used for running builds on NixOS!
It seem to be packaged by but only for macOS. If i understand the project correctly, that makes no sense. We want it on linux, to run macOS apps. Also, the package has no version. That's probably because they havn't tagged a version yet. So this is pre-alpha state software. could you update the package to the commit the "stable" AUR package uses and add a version as described here: ? Then we can close this issue.
It looks like the project has started using tagged versions:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
I'd still be very interested in seeing this , especially with the hope of future cross-compilation support
This would even make it possible to package Mac binaries for Linux!
I'm interested in this so that I can test cross compiled binaries when running tests.
I marked this as stale due to inactivity. →
Not stale!!
darling-dmg is just part of . To be exact, it is included as a submodule in the source tree of darling. The darling build will come with kernel modules. It would need someone with kernel-packaging experience to pack it into Nixpkgs. Build instructions in the Darling Docs:
I marked this as stale due to inactivity.


→
I'd still like to see this, though largely for much the same reason Andrew mentions at this point -- I've started working with zig and being able to test cross-compiled macos binaries would be brilliant.
I have got most of a Darling build file running, but I have found an interesting issue. Wever I build I get the following error: From this cmake file: As far as I can tell, the command is a special MacOS thing, and I unfortunately do not understand CMake well enough to fix it...
Well, turns out the issue is that Darling relies on git-submodules, and it looks like this must be built against the Git repo directly, not against the released tarball...
What would therefore be a derivation?
What do you mean It's just a with .
I tried to re-package the prebuilt deb from darling GitHub releases. Here is the nix code darling- Save these 2 snippets as and darling-, then run . With 2 problems: needs setuid/setgid perms, while nix-build would fail if dpkg-deb -x executed directly. I use fakeroot to ignore this problem. always fails. I am not a darling expert, have no idea.
Ah, fantastic, thanks! Looking forward to having this in nixpkgs anyway, but let's see how we go there.
It could be named when entering Nixpkgs.
Good suggestion. I've edited those two scripts.
I got as far as finding out that darlingserver doesn't start with that script because it expects /usr/bin, so updating my to a version, the next issue was that darlingserver was trying to mount overlayfs on "lowerdir=/usr/libexec/darling,up" (may be incomplete, this is strace output) which did not exist.
After a bit of tinkering I got Darling to build from source. I opened with more info. Please give it a try!
It seems that they now use instead of the kernel module. This would make packaging easier.
What's the purpose of ? If it is only the sandbox part of Darling, a new name like would bring less confusion. Update: Opened PR to do the renaming.


Describe the bug Starting slack doesn't show the window in 8 out of 10 runs To Reproduce Steps to reproduce the behavior: Expected behavior Slack window should open Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(ymatsiuk): channels(root): nixpkgs: Maintainer information:


Project description CoreCtrl is a Free and Open Source GNU/Linux application that allows you to control with ease your computer hardware using application profiles. It aims to be flexible, comfortable and accessible to regular users. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux
It looks very complicated. I will look at AUR.
sorry for the late reply thank you very much for looking into it :relaxed:
Well, I will do what I can do. I am not a huge user and packager of such graphical things, but it looks an interesting project to take on. I will do some research.


Project description qpsolvers is python library for solving quadratic programming problems. It contains wrappers for multiple solvers like osqp, cvxopt, quadprog and much more. Metadata homepage URL: source URL: license: LGPLv3 platforms: platform independent (python3.10)
This package wants new version of and new package - . I will try add PR today, but now you can use my NUR repo if you want:


In the latest stable release, the package fcitx5-openbangla-keyboard does not work. OpenBangla Keyboard package is installed but it does not integrate with fcitx5. fcitx5 crashes every time after logging in.
Here are some screenshots. ! ! !
Thanks for reporting, will take a look.
... Here is my !
Any update? Thanks.
fcitx5 crash log:
I have forked the OpenBangla Keyboard from the develop branch. After the recent commit. it built successfully in NixOS. I am now using OpenBangla Keyboard with an overlay from OpenBangla Keyboard's develop branch. !
I think change of these two lines according to this image will solve the problem. ( I don't know the correct hash = sha256, I just gave this and the correct hash was shown in the build error!) !
Thanks for looking into this. I've pulled the relevant commit and also tested at runtime this time, it does not appear to crash and outputs text properly.


openbangla keyboard installed from the unstable channel does not integrate with fcitx5. It installs just fine but does not integrate with fcitx5. Fcitx5 does not autostart too. OS: NixOS Stable DE: KDE Plasma !
Openbangla keyboard from unstable channel does not work in the unstable nix os installation too. Openbangla keyboard crashes fcitx5 and even if it is restarted switching keyboard layout says openbangla keyboard not available.


When you set , although it sets the CMAKE flag correctly the resulting package isn't actually built correctly as cmake can't find cuda so it unsets the flag. This is due to the incorrect usage of instead of when building the cuda related packages. The correct usage can be seen in the package. It also tries to build with CUDA by default which is wrong. Dlib hasn't supported fftw since however there are leftover references to it in cmake which might lead people to think it does support fftw. fftw should be removed. As mentioned in this it makes more sense to have as an input into rather that so that people can override it with other BLAS implementations e.g more easily if they want to. The package was also missing lapack which should be . Steps to reproduce the behavior: Build the package, it tries to build with CUDA by default. I made an example with a fairly simple nix flake that let's you switch between my patch and the original package. I have created a which fixes these issues. For it to build with CUDA. How CMAKE fails ! For this simple c switching from my fix to the original bugged package on 23.11 before openblas was . ! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Thanks!


Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection


Reproducing is pretty simple: . The error is: system: host os: multi-user?: sandbox: version: channels(philipp): channels(root): nixpkgs:


to newer version to different directory as under postgresql user Output I get:
The NixOS service module for PostgreSQL, for some unfathomable reason, initializes new databases using a non-standard superuser role name ( instead of ). This makes it a nightmare to get to work right, so forget that. Instead: back to your old version of postgresql root, dump your entire database to a file somewhere: to the new version of postgresql root, read in the database dump: (you'll likely see an error go by about the role already existing, you can ignore this) For good measure I went and tested this upgrading a 9.2 database to 9.4 under NixOS, worked fine, the applications using it continued on as normal after the import. That said, the real issue here is: why are we initializing databases using a non-standard install / superuser role name?
cc
See regarding the superuser role name.
Shouldn't we switch the default user to "postgres" on new databases and keep the "root" account around for existing-ones ? See
I strongly agree we should switch the default superuser to . Currently, it seems impossible to use to upgrade postgresql databases due to NixOS using the superuser: simply refuses to run as root.
The approach given by above doesn't work for me:
I can submit the change as a PR but don't use postgresql and it needs testing. Feel free to steal it and do the upgrade process with it.
pgdumpall tends to e pretty useless if you database isn't tiny_ :(
that would be a good start :)
there you go :)
FYI: I've just tested migrating 9.2 to 9.6 using and it works flawlessly.
Ok, I think I found out why wasn't working for me, like I mentioned in It seems to be due to this line in the Hydra module: If I change the mapping to then the command works fine. But I'm not exactly sure what are the implications of doing this, or why was mapped to in the first place...
In case someone runs into the same issue as me, I am documenting the procedure I used to upgrade a PostgreSQL database that was being used (only) for Hydra.


I tried to follow procedure above, but as I mentioned before, to use as suggested I needed to change the PostgreSQL user mapping in the Hydra module as specified in my comment just above this one, otherwise I would get a message. However, to read the database dump back into the new PostgreSQL installation I had to change the user mapping as follows: ... and then, after activating the configuration, I needed to run the command in the following way (as root): After doing this, the upgrade from PostgreSQL 9.4 to 9.6 seems to have completed successfully.
Related
If anyone else stumbles on this, pgupgrade seems to work now. I realized after upgrade that my db got reinitialized, so steps for me were much more brutish than that post, but in a nutshell: with new postgresql running, clear whatever got reinitialized (pgupgrade won't run if there are data around, but won't tell you what to remove... lists databases, don't know how to list users, I guessed) drop database whatever; drop user whatever; stop postgresql.service figure path for old binaries, e.g. and copy it somewhere. run the actual pgupgrade as user: restart the postgresql service if all went well after some testing pgupgrade suggests removing the old db with (disclaimer: Don't blame me if that eats your data)


I get errors like: This shared object is provided by derivation, not i.e:
Just some additional info: using the wrapper script provided by doesn't solve it either.
I would like to hear from someone more experienced, but maybe an aggregate package (like for texLive) could solve this.
You are right. I was talking about the PulseAudio plugin simply because I believe that it is the only plugin used by almost everyone. Other plugins are kind of “special”, or “professional” and can be dealt with on per-expression basis, but the PulseAudio plugin should work out of the box without any extra configuration from the user or the expression maintainer.
BTW I just found this topic from 2009 with a relevant discussion: An aggregate package seems to be a viable solution. The problem with this (which seems to be the one concerning in the ML) is that adding plugins won’t be possible without rebuilds.
It's really tricky because ALSAPLUGINDIRS is a compiletime constant in alsa-lib. (so the env-var approach won't work) I tried to add a dir for plugins like for the graphics drivers to /run/alsa-plugins. The problem with this is that alsa-lib builds smixer into ALSAPLUGINDIRS so it has to be inside the derivation. You can pass the configure flag --disable-mixer an then alsa-lib will build, but then gstreamer won't build anymore (i guess it tries to link against the smixer in alsa-lib). I haven't tried the aggregate package yet because I'm not sure how to make everything use the aggregate derivation instead of the alsa-lib.
By the way, looks like should be removed. Looks like there used to be a in Nixpkgs that made respect this environment variable, but now it is .
Shouldn’t the commit that removed the “unused” variable be reverted? I mean, we need a beautiful solution, but at least it worked before that.
All the plugin so-files are relatively small in comparison to libasound (<300 kB together vs. ~1.4 MB), so we might consider having the default attribute contain the plugins needed for pulseaudio playback. Our attribute no longer needs to build, so we should be able to reverse the dependency and make depend on . /cc should know more about pulseaudio packaging. Perhaps it's a similar situation in there.


I was thinking about integrating the alsaPlugins into the alsaLib derivation altogether. (I need the jack plugin as well) It may not be an elegant solution but it's not that big an overhead (maybe some dependencies will need adjustments) And build all the plugins that are buildable. Also I think the workaround was removed in official alsa project. See Dynamic Loader helpers section here:
I'm using this workaround right now:
Also see , which maybe adds more complexity to this issue because of a 32-bit library / 64-bit plugin mismatch.
(triage) status?
I think I'm seeing an effect of this in attempting to update the Factorio derivation, but master nixpkgs has a more up to date version of alsaLib, but it appears to be trying to load the plugins from the system installed version of alsaPlugins.
I also got hit by this issue while trying to run Nix-installed Audacity 2.2.2 (from nixpkgs master) on Ubuntu 14.04. Audacity playback doesn't make any sound because, it seems, hardcodes its plugin search directory.
I worked around this by creating a directory containing a symbolic link to and adding that directory to .
I've found a workaround in Guix manual alsaPlugins the following lines to ~/.asoundrc or
Wow. Thanks for the tip gnidorah <:
Still relevant in 19.09 :/ Does anyone know the syntax for importing rate conversion plugins ("speexrate", "samplerate", etc.) directly inside "", or if there's a method without hackery by now? Btw, seems to be affected by this, I'm using your workaround from here right now, together with .
Meanwhile it is even ALSAPLUGINDIR instead of ALSAPLUGINDIRS (notice the missing plural 'S')
we could patch like so. But beware, this is actually only for the the second time that i am patching c code. I tried it with and the converter and it's working so far. <details<summaryenvironment-plugin-</summary</details
Or we could just bring back the original patch.


i guess it is still here (somehow :)) but it is doing nothing for loading rate converters since they are neither loaded through patched from nor through from but through from But yes, now that i reread your comment, that way of telling alsa where to find libs is gone.
Since I opened this issue I'm not sure what to do with it, but since learning more about alsa config this is no longer an issue for me. I'll post my config hoping it helps people: I have in my And my config looks like this: This finds the jack plugin just fine due to the If I want to run something (for example steam) that won't be able to run with jack then I just fallback to my mixing PCM with stopping jack exporting
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
This still needs to be addressed (either by the wrapper or by patching the package, maybe both). I've been using the same trick as and it works well enough, but it'd have been great to have the package itself or the wrapper handle users' additional plugin paths out of the box.
With the release of v1.2.4 on 19 Oct, alsa-lib gained official support for an runtime environment variable. It was in , following with some Guix folks. Note that this environment variable only supports a single directory, unlike the (effectively unused?) alsa-plugin-conf- which provided a plural environment variable.


One nice effect is that we don't have to patch alsa-libs any more. Thoughts on how to best take advantage of the new feature?
Without writing an updated patch for multiple plugin directory support, the upstream's can probably be put to use immediately by pointing to symlink farm of plugins. Haven't tried this, but I suspect it (or something similar) would do the trick. The linked GUIX thread included review of a patch for multiple plugin directory support. It looked promising but its growing stale with outstanding feedback. They've not responded to news of upstream ; I do wonder if they'd consider contributing their multi-directory patch or not - especially given that there's now some kind of upstream support.
Guix's property will automatically create a create a symlink union of the relevant plugins for single-entry search paths. It's how Chromium extensions and plugins are discovered, for example. It's just because we haven't gotten around to update alsa-lib yet, as it missed the latest 'staging' cycle.
Hi, I'm the author of that patch from Guix, although it grew out my reading of the old unused nixpkgs patch. I ran out of energy for keeping track of all the "C issues" one has to think about... if alsa-lib's new ALSAPLUGINDIR meets our needs then I'll be glad to leave the patch behind. Feel free to use the patch in any way you like — it does work fine and, as a part of Guix, the license is GPL3+. Or, as a part of alsa-lib, maybe it's LGPL2.1+? Anyways, feel free...
I marked this as stale due to inactivity. →
I implemented the aggregate package approach () and appreciate your thoughts on it.


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


Restart cinnamon from the panel freezes the desktop, from the journal you will find cinnamon crashes. click the panel trouble shooting cinnamon No crash.
Okay, I guess I need upstream help for this, going to forward this to upstream...


Packaged VLC does not seem to support wayland. Steps to reproduce the behavior: vlc with on e.g. sway opens as a XWayland window VLC opens as a Wayland native window Not applicable Possibly related to VLC not depending on qtwayland. Please run and paste the result. EDIT: Typo
It is strange. I built it and verified, it is not linked with QT libraries even if they are put as inputs.
Is also pulled in as an input?
Nope. Working on it now. First encounter: Wayland is considered experimental and disabled by default.
Can you test the patch?
Works like a charm, thanks a lot! :)
I'm on NixOS 23.05 and discovered that vlc prefers to use XWayland if var is set. If I unset then vlc starts in Wayland mode. Does anyone know how to make it to start on Wayland by default?
For now I hacked it with: Special thanks to
Well, if this is hardcoded on VLC, there is nothing to do (besides maybe searching some hidden commandline flag).
The "use QTQPAPLATFORM be damned" behavior is apparently just what QT does, and is not specific to VLC
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Here is the updated wrap that also addresses the desktop file


After setting up faster-whisper for my Home Assistant instance, I learned that my CPU (i5-6500) isn't quite as fast as I'd like for this, so I am now trying to test a GPU (NVIDIA Quadro M2000). My configuration for it is the following: I expected it to then run on my GPU using CUDA, but unless my GPU and CPU are continually equally performant, it is not working. (Also, no processes are shown in ) Steps to reproduce the behavior: NVIDIA GPU, and then configure it accordingly in , add , , , and to faster-whisper in configuration, configure it to work with device = "cuda" for STT to be faster, instead same speed I'm not totally sure what to expect because this is my first time using this, but I expected a Python3 process to appear in and for my STT to be quicker. My config is the following: The following (seemingly) NVIDIA related items are at /dev/ ! ! works, but I am not totally sure that my CUDA is configured correctly, for all I know possibly CUDA isn't configured properly, but I think I have everything correct.
I eyeballed CUDA support, but have no hardware to test or reproduce. I appreciate help in fixing the module to make it work with CUDA.
I am not overly proficient in Nix or anything like this, but I would be willing to help if you have ideas.
Well, for one we're not passing in . Can you try setting ?
Ok, I that and now when looking at the logs, I get this: It then exits.
That looks actionable. We did indeed not build ctranslate2 with CUDA support. I can try to set that up, but it won't be the default, because that would make the package unfree. We possibly need multiple ctranslate2 attributes.
Is it possible to have the package be free unless an option is passed that enables CUDA and then makes it unfree, or would two different packages be needed. There could be a package, I think that could work.
Yeah, that would also work.
If you want to try and build it with CUDA support, I can test it out and report back.
fixes the module, so it passes as expected. It also adds CUDA support to .


Check the description of the PR on how to opt into CUDA support in nixpkgs.
Hi Just to clarify, you only need in your (or in your 's ) if you're setting up a development environment to write cuda programs. If you only want to use packages with cuda support enabled, you just use them directly (e.g. ), no need to add anywhere manually. If you want to enable cuda in every package that supports it, you can set in your (nb: this triggers a massive rebuild). Instead of adding , you want to use (this way if you switch e.g. -, you'd be still using for the correct kernel), but also instead of you can take (keeps working if you switch e.g. -) Sorry we didn't get this documented yet
Wow, thank you! I assume I still need in my , right? About enabling , I've already enabled that and let it go through that whole process, so I think I'll just leave it enabled. About changing the , how is that to be done exactly? Do I just swap for in the exact same spot?
Also, is there an easy way for me to test out this updated package before it gets merged?
Depends on how you deploy your machine and what nixos version you are on.
I'm on Unstable and use Flakes.
You could replace your nixpkgs input with a fork of nixos-unstable and pick the commits from that PR on top. I'm sure there is a better solution, but I'm not well versed in flakes.
No, is the old version of , and you don't need it in Yes, except it's just , without at the end. This refers to "whatever graphics driver is in use". But also you can just remove this if you use and (both options are badly named, they're not really specific to neither of opengl or x11)
I have , but I don't have xserver enabled because this is a headless server. Do I even need nvidia_x11 if it's headless with no DE?
is where comes from; I don't recall now if it's ok to use on a headless machine, but if you like to just be explicit, you can keep P.S.


Discourse and NixOS matrix channels provide venues for Q&A discussions
With the changes made to ctranslate2, and the fixes to th , I fully expect this could work. If not, please get back to me with some error messages, e.g. the hardening of the systemd unit might cause problems.
No problem. I attempted to use just the new packages, but it became a little difficult because my old nixpkgs didn't think that ctranslate2 could have CUDA enabled, so I'll just wait for master to get pushed to NixOS-Unstable (Hopefully soon!)
The package now fails with . My system may not be correctly configured for CUDA support, or the SystemD Service is not passing through the NVIDIA device correctly. Just a reminder, the following devices are available at : (I'm not sure if is an NVIDIA thing, but it exists if that's of importance.)
Then we're at least missing . What's the content of ? nix DeviceAllow = if [ "cuda" "auto" ] then [ # "/dev/nvidia1" "/dev/nvidia2" "/dev/nvidia3" "/dev/nvidia4" "/dev/nvidia-caps/nvidia-cap1" "/dev/nvidia-caps/nvidia-cap2" "/dev/nvidiactl" "/dev/nvidia-modeset" "/dev/nvidia-uvm" "/dev/nvidia-uvm-tools" ] else "";
I modified the SystemD service to include , and it didn't help at all. The contents of are . Also, I just discovered something new. When running I get So possibly updating this system now broke NVIDIA support and it just so happened to be at the same time I tried to get Whisper working.
Did you also check which is in ? There are two things you need to maintain: 1) your driver should be newer than the cuda libraries used to build your program, 2) your should come from the same (version of) package as the kernel modules (in other words, currently you have to reboot if you update your nixos and get a newer - the new kernel module is only loaded on the next boot)
shows the following for Also, I just rebooted and is working.
from what I listed is accessible from , should my system have functional CUDA support? I tried using some testing parts from , but it seems to be out of date.


PS: Should this conversation be continued somewhere else, or is it fine to continue it here because it is somewhat pertinent to the issue?
Yes please, e.g. in or , or on You can just post the final update here once you get things to work, for discoverability purposes. Thanks!


Can't build xorriso due to source archive hash mismatch. Steps to reproduce the behavior: the substituter -shell -p xorriso nixpkgs 23.11.5408.
Probably it comes from a moving target... Let's go!
How exactly it happened? Here is the url: Is web archive failing?? P.S.: since Xorriso is just another name for libisoburn, I will remove xorriso and link-alias it to libisoburn.


Project description vcpkg is a package manager for C++ and many large and very small libraries are packaged there. Many of my projects use it for CMake configuration and for its toolchain file that automatically download and build libraries. I want to setup dev environment with nix and this is one of the packages I'm looking for that I've been building manually (since the brew packaged vcpkg is not well configured for manifest files support) Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, windows
I'll try something now.
Reading the , it looks like a case for a module, not merely a package.
I'm not sure what's the difference between a package and a module... but if it allows me to download a prebuilt binary of vcpkg that I can simply install, that's fine for me. Know that this package manager is made (partly) in C++ and need compiling. The build script is the you see there.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Maybe I am over-engineering here. Reading the AUR script, vcpkg uses systemd scripts/services. Therefore I think it requires more integration with the operating system. Modules are, roughly speaking, designed to "patch" and configure NixOS (the operating system).
Would be nice to have!
Work is ongoing here:


Python module, corresponding to the package and exposing its functionality in Python programs, fails to import, despite being included in . module is imported successfully. n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- (as maintainer) (as the one who exposed the Python bindings) Please run and paste the result.
Note: it seems like the module doesn't work even on commits that introduced it properly... To verify, run in a Nixpkgs checkout:
Yeah, I screwed up testing this. btrfs-progs doesn't propagate python, so I was using my system (non-NixOS) Python installation without noticing. should fix it.


I have a system without Command Line Tools or XCode and nix'es cmake can't find headers and tries to pick up system frameworks. Try to build this: On my system I get: System: Darwin Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: 17.09pre-git () Sandboxing enabled: no
Related to


The gitlab  script depends on , which was removed by in . Steps to reproduce the behavior: The update scripts succeeds. (myself) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Also looks like nix-update could be used here.
Ok. looks like switching to nix-update would require some other major refactoring because the writes out some json file out. But here is a simpler approach:


Describe the bug to the find call. This prevents things in the that are symlinks from being wrapped. Noticed this during office-hours when wasn't wrapped anymore. We should add some code like there is in or revert the . To Reproduce Steps to reproduce the behavior: a binary into or the thing and notice the binary isn't wrapped.


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


Package name: gpt4all Latest released version: 3.2.1 <!-- Search your package here: --- Current version on the unstable channel: 2.8.0 Current version on the stable/release channel: 2.7.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]:
Hi, I don't maintain GPT4All any longer, I switched to some other technologies (Open-WebUI).
haha, maybe i'll give that one a try then :) ty for all your hard work


It would be great to have option to fetch nnn plugins with nxpkgs or with additional package instead of manually fetching it like developer advise. And second is it possible to implement some option to include icons support from nerdfont to nnn binary file instead of recompiling it? Thanks.
I think this issue was closed preemptively by the line in the PR, there doesn't seem to be any way to include plugins as of now
nnn seems to expect plugins in . This might work better as a home-manager module, maybe with the plugins themselves as an output of nixpkgs. I might take a look at this next week.
I marked this as stale due to inactivity. →
I've recompiled nnn with icons, by using unstable branch and overriding nnn-package:
I marked this as stale due to inactivity. →


is failing with: Steps to reproduce the behavior: Result: It should work. N/A I need to use netplan locally to test generated configs, I don't actually need to apply them locally. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description Glue is a python project to link visualizations of scientific datasets across many files. Click on the image for a quick demo: ! Metadata homepage URL: source URL: license: BSD Linux, BSD


Since Sage is huge and complicated, I figured I would make this issue to collaboratively track progress and share branches. One big issue is that Sage 7 , instead they use some with scant documentation . has the correct SHA256 for Sage 7.6 and updates a patch file. It currently fails when Sage tries to build . Some nice things to do for the future: ) cc:
thanks for picking this up
Me myself being a miserable loser who has failed to update Sage in the past, I hope you succeed… My attempt hit the following wall. It is unbearably slow to let Sage build everything, but when I had convinced it to use the system versions of majority of dependencies it began to complain cryptically about their interaction in some case.
Can you elaborate? Do you have a branch that has that work? Also, to be clear: I probably don't have the skills or time to upgrade Sage by myself, I was hoping that if we shared our knowledge and de-duplicated efforts we might be able to get closer together
I think it was 6-dot-something; it required a metric ton of adding options to the packages in NixPkgs (I have pushed that all to master long ago), and the Sage tricks are most likely too version-specific. It was long enough ago that I have since abandoned and lost the changes.
In case anybody in here is still waiting for this: I got sage to compile and run. I'm currently trying to minimize the dependencies and check that everything is working correctly (there is one doctest failure, but it was mentioned multiple times in the mailing list and apperas to be harmles -- just a timeout). I'll probably make a PR in the next couple of days.


Sage needs texlive-core-2014, which is deprecated. Run with modern nixpkgs (i.e. from git) System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:


Chromium coredumps on wayland/sway when trying to share a screen. Steps to reproduce the behavior: sway/wayland "" on "share screen" anywhere -Dump A selector for the screen to share should appear According chromium setting: According nixos configuration: Console output when the error occurs: Also this works fine with firefox-wayland and used to work with chromium. <!-- 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.
Could be related to as it also states
Did screen sharing work before / is that crash (segmentation fault) new? And do you know since which version it stopped working? So far screen sharing did never work reliably and there have been frequent regressions: (I've fixed it twice on my test setup but I've given up since then). We might want to close this issue in favor of to keep the discussion in one place.
For me, screenshare works on Chromium v99, and stopped working after update to v100
For me it also worked in the past without issues. This is new and this is chrome core-dumping. This is a different issue. If screen sharing did not work in the past, it just did not work. It did not cause an out of bounds read or crash of the browser. Please don't close this issue.
Sure, we can leave it open. We should mention it in the other issue though (I just did that) for better visibility. Now we need someone with time and motivation to handle this issue (analyzing the issue, searching for upstream issues, etc. and eventually someone needs to submit a fix).
Since this is NixOS and we have the boon of input-reproducibility and a binary cache, could you post: the nixpkgs commit you are on the nix store path of your chromium binary This will make it even easier for others to reproduce. You may also be able to get the stack trace with GDB using , use , make the segfault happen, and use in GDB.


nixpkgs: /nix/store/07346c7jv5wnwg30r5dvmlgqbk52hinz-chromium-100.0.4896.60/bin/chromium
Regarding gdb: ` How do I get gdb on the actual executable but keep the env vars of the shell script wrapper?
Now edit , replacing like this: Then terminate all chromium instances (to avoid joining existing instances), and run .
Thank you for the detailed instructions!
Looks like it should be fixed in m101
I tried to build chromiumDev(102) or chrimiumBeta (101) - but both failed with errors related to:
This patch may be useful: https://webrtc-
I'm a week old to nix, but trying to figure out a way to patch it. It seems it needs a special flag due to it's location:
building chrome is an undertaking not to be embarked on lightly. you can install the chrome dev or beta channel package. On my up-to-date, flakes-enabled nixos-unstable: The issue seems fixed there. There are builds of chromium upstream here: (under other), but I'm not sure if there is a nix derivation for them.
I've opened for a quick and dirty fix - the code isn't pretty but should do the job (I wish would support Base64 patches or even better: Gerrit and gitiles would support fetching patches using a sane format like basically any other web VCS frontend does...). Anyway, I'll check if the VM test passes (although that patch is so trivial that it should be unnecessary) and can merge the fix tomorrow.
I love the name and thanks a lot for your time & effort!


Describe the bug is when building for MinGW, however an equivalent GCC 10 patch file doesn't exist. I tried looking for a GCC 10 patch on the master branch of , but the folder that contained the patches no longer exists. GCC9 is still currently the default on master, but this will break everything under MinGW the next time staging-next is merged to master. See Support for was originally in To Reproduce Steps to reproduce the behavior: Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(kira): nixpkgs: Maintainer information:
It has been moved to to upstream migration. Neither of these repos is stable; their master branches are constantly rebased on upstream and force-pushed.


Since was merged into the master, swift cannot be built on aarch64. Steps to reproduce the behavior: reported in I'm not familiar with swift or clang, but I'm using the following overlay as a workaround until it's fixed. <!-- 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]:
states that this only fixed the swift build but all downstream packages are still broken. re-opening.
Actually, it seems only dark-mode-notify is broken, others seem fine. Probably because it uses Cocoa or disables sandbox. I don't know for sure.
I noticed that my personal package does not build either. Maybe it's because of swift itself or swiftpm?
The above open PR seems to run into the same issue…


uses two actions and do get necessary authorization via . but these actions are not properly registed, leading to error: (It can be verified that these actions don't exist by using ) This breaks and . I tried both pcsclite 1.9.5 and 2.0.1 ending up with the same error. Steps to reproduce the behavior: and in , configure your smartcard (yubikey) to use yubikey error There actions are registered correctly and usable. Please run and paste the result. I'm using flakes (no channels). Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
correct description of your effect, i am not able to use my yubikey with gpg.
This can be solved by
this works, thanks! but this is really unintuitive, given that is already adding the package to : I am leaving this open as I believe a proper fix should be provided in the module itself.
Same issue here. It was working approx. last Dec. I don't have a specific commit hash. Adding to works for me.
Looks like a regression in () - is implying to me that polkit actions get included in the output, however: isn't included, which explains why adding to fixes the issue. Solution ideas: Add to . Not sure about this one? seems to also contain some libraries that probably don't need to be installed. Install polkit actions to instead of . IMO this one makes the most sense, especially as it seems to have been the previous behaviour before this change.
I was bitten by this when attempting to update over the weekend as well. In my case it prevented login because I use smartcards for user login which made debugging difficult due to the number of reboots required. I tend to agree with that going back to having the polkit actions file in the output instead of makes the most sense. That will mean that of the pcsc module will again result in the polkit action file being to the system configuration.
Cc: ()
I also think the location should be fine, the files are also there.
I ran into this issue when I couldn't access my yubikey anymore via pcsc for commits. The above solution worked for me.


I'm going to add some comments for SEO so this is easier to find
I think you have found the right culprit that caused the issue, but I suppose the issue has more to do with the itself, where it only includes if . This has been rectified in from what it seems. For now the proper solution seems to enabling polkit with .
I think that makes more sense based on the existing file structure but maybe we just switch bin to out, so it is the default and move the libs to lib instead of being in out.
I've created to make the outputs a lot more expected by moving the udev file and the systemd service to the out output and the libraries to the lib output: I didn't test it yet, so it is still in draft. If someone could verify that it doesn't break security keys again, that would be great and then please undraft it, otherwise I do it in the evening.
I do not think I can fully test this due to the amount of rebuilds, so please chime in for reviews and find the one mistake I might have done (which I hope I didn't)
Tried to build but it fails on my machine:
I've xdist to dulwich here . Let me see if we can just disable some tests as a speed up from 66s to 9s is quite good.
This should be a lot better with . I did a lot of rebuilds locally on a low and high core machine and didn't encounter any failures anymore.
This was fixed in , works fine for me.


When executing switch-to-configuration in a pure environment it fails: I am calling switch-to-configuration via systemd-run to active a new profile using the Hail update tool. The actual executed script is as follows: Actual output: <preactivating the configuration... perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LCALL = (unset), LANG = "enUS.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). setting up /etc... perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LCALL = (unset), LANG = "enUS.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). setting up tmpfiles Too few arguments. sh: systemctl: command not found </preThe script works if I pass on the PATH and LOCALE_ARCHIVE environment variables: System: (NixOS: 17.09pre-git (Hummingbird)) Nix version: nix-env (Nix) 1.11.13 Nixpkgs version: nixos-unstable (Commit ) Sandboxing enabled: no (Related Hail issue: )


Steps to reproduce the behavior: dvc actually it is hash problem. error from my nixos: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This happens not for the first time and probably not for the last time :cry:


Project description Emmet support based on LSP. Metadata source URL: license: mit platforms: all


Steps to reproduce the behavior: on old thinkpad Device: Thinkpad X220 <!-- 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.
greetings ! are you able to test ? an other workaround is to stick to < 6.4 kernel
for now I can't test your commit since I'm newbie and asking you to teach me would take a lot of your time Gonna stick to < 6.4 kernel and try to test commit in free time
appreciate your concerns! from looking at your setup you seem to know fair bit already, and I dont mind spending some time for as long we all learn something useful you should be able to test that PR by changing in your flake to edit: also no rush to test this
Well that was actually easy to test! PR works! I thought I need to use overlays to test it and I have zero experience with them for now.


Steps to reproduce the behavior: onionshare <!-- 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]:
The package distutils was remove in Python 3.12. Depends on upsteam. I raised a PR for the fix:


The component of the derivation fails to compile on MacOS. But in two ways, and I can't tell what causes one or the other to trigger. On command: On command: the channel compilation failure Compiles.
It has been broken for a while now for different reasons. Maintaining it for darwin is a lot of work and nobody has stepped up to do that. Also, this is a duplicate of
By the way, what is your use case for ?
We're building a desktop version of mobile application and we need for our in-app browser with Ethereum support.