Steps to reproduce the behavior: kvmfr <!-- 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]:


Steps to reproduce the behavior: x3270 on darwin fails due to missing macOs dependencies (libiconv/Security) The are a few things missing that are need to get this to work on macOS use & link iconv use Security package for headers disable x3270 build (the other unix builds are fine) Please run and paste the result. I have a fixed package for this that I can open a PR for


Package name: i3bar-river Latest released version: 0.1.7 <!-- Search your package here: --- Current version on the unstable channel: 0.1.6 Current version on the stable/release channel: 0.1.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]:
I looked into this a couple days ago. The problem is that 0.1.7 makes use of a features introduced in Rust 1.77. NixOS isn't there yet, so I don't think this package can be updated just yet.


Project description ab-av1 is a VMAF-based reencoding frontend for ffmpeg, primarily for av1 but works well with x265 and other encoders. It is a rust project and requires ffmpeg newer than git-2022-02-24 with libsvtav1, libvmaf, libopus enabled. Metadata homepage URL: source URL: license: MIT platforms: unix, linux, darwin, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


A clear and concise description of what the bug is. The integration seem to require the missing python module and currently fails with this error message: is provided by python . Adding to in the . Maybe this missing dependency could be resolved in pyowm as well. I would appreciate some input from somebody with more experience. Steps to reproduce the behavior: home-assistant with openweathermap component No Error message and working openweathermap component <!-- 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]:
PR
Please post the full stacktrace.
There also was an upstream issue that may be related:
The fix is to add to pyowm's dependencies.
ok. Thanks for your help. I will create another PR later


OAuth2 Proxy's Nginx plugin used to forward and headers to downstream programs. This stopped working after I updated on unstable channel, which is potentially related to or . Steps to reproduce the behavior: up OAuth2 Proxy + Nginx up of header name . does not recognize the session More simply: up OAuth2 Proxy + Nginx or something similar the headers — and used to be present, but not anymore and are passed to downstream servers under Nginx. I have I went on upgrade of nixpkgs unstable from sometime late January to a few hours ago, which is what led me to the two PRs mentioned above. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
are you able to play around a bit and confirm if the changes mentioned introduced this regression?
yes. I can't really pin-point to what exactly since there were a lot of changes. Instead, I just have a local fork from (prior to the changes mentioned in the PRs above).
I have a pretty good idea what it could be.
Can you give a try? I didn't test it yet, so it could completely break everything and be completely insecure, just as warning.
fantastic work please let us know how it goes
Sorry for the late reply, I haven't been able to have time to test it out. Now that I do, it seems like has been converted to . This won't be an easy find-and-replace for me to try in my setup, so I will have to find some time to do proper cleanup.


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


Package name: gummy Latest released version: 0.6.0 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.3 <!-- 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! --- There is an open pull request () by from October 2023, but it has not been merged and later versions of the program have been released since then. I think it is also worth noting that the source code repository of the is no longer available on GitHub. as the repository has moved to Codeberg (see ). Notify maintainers (last updated the package) <!-- 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]:
I updated my linked PR to the latest version.
Thank you for updating it so quickly! Is there a time frame in which we can expect the pull request to be merged by someone?


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


example: This one is low on the massive bucket list, but extending the number of retries and the timeout between each retry will reduce friction.
This might be caused by , in which case increasing the timeout wouldn't help much. We can try though, PR appreciated!
please view


When installing usbimager the path in the desktop file is /usr/bin/usbimager, so when you try to open the application it doesn't open, to fix it you have to copy the desktop file from /run/current-system/sw/share/applications/usbimager.desktop to and edit the desktop so it reads Exec=usbimager Install usbimager, try to open the application from your menu, at least this is the behaviour on xfce, I've not tested it on other desktop environments system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Does it work in a nix-shell? nix-shell -p usbimager usbimager Worked perfectly for me on hyprland.
It works in a shell, it also works when installed system wide when you launch it from a terminal, its when you try and launch it from a menu like xfce's whiskermenu it doesn't launch, because the desktop file has Exec=/usr/bin/usbimager


Koodo reader is an electron application, and although the build process to add the proper ozone flags when the app is launched in a Wayland environment, it seems for some reason, it's not working as expected: But launching the app with the required flags, it works: The process arguments seem weird: Notice that the the by the package are truncated after the first space . I tried splitting up the flag into two sentences to avoid spaces: But now it looks l like the process does not pick up the environment variables: The variables exist, I define them as . Changing the above override to explicitly set the ozone flags (without the shell expansion conditional) works. Other packages like do the same shell expansion, and they also work in my environment without overriding anything. Steps to reproduce the behavior: in a wayland environment (I'm using hyprland) if the application is using xwayland by running shows the application again but with the ozone flags the app does not use xwayland: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm not a wayland user, so I usually just copy this line from other electron apps' definitions and hope it works. I think the issue here is that when is present will use the binary implementation, which doesn't expand shell variables, thus not making this work. It looks like I forgot about this behaviour when packaging this.


Package name: ms-vscode.cpptools Latest released version: 1.20.2 <!-- Search your package here: --- Current version on the unstable channel: 1.17.3 Current version on the stable/release channel: 1.17.3 <!-- 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]:


Steps to reproduce the behavior: python311Packages.dulwich Package recently updated and maintainer used the wrong source tarball path Used but should be Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


No crash n/a n/a Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Same problem, same message, with the following system. WM: sway
Attempted hacky workaround from This changes error to Progress?


A clear and concise description of what the bug is. In , XDGSESSIONTYPE is now set to wayland by default for Hyprland users. However, SDDM will crash when this env var is set. Steps to reproduce the behavior: SDDM with Set under . SDDM greet will never show, and the screen will be black. These two lines can be seen in journalctl, and they are not present for boots from older generations. SDDM does not crash. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Did you enable wayland support for SDDM? ()
Thanks, enabling that option fixed the issue! Would be nice if there is an config assertion for this.
Haven't checked the implications but maybe sddm should just enable by default?
enabling wayland for SDDM, makes it impossible for me to start X11 only sessions (eg Pantheon) Is this expected, or is there a way to use SDDM with wayland and X11 sessions?
Same issue here, workaround mentioned in worked for me. I found the following stacktrace in the logs, not sure if/ how this might be helpful.
The proper workaround for now would be to set . Those are envvars that should be set only when the hyprland session starts, not categorically set.
Thanks, this worked for me. I can now start X11 sessions again :)
Same problem here using Hyprland with Budgie as a second desktop. Thanks for solution :+1: works!


Package name: LLVM Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 18.1.4 Current version on the stable/release channel: 18.1.4 <!-- 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]:
Want to submit a PR? The last upgrade was very straightforward:
I'll give it a shot


For Intel dGPUs, requires in order to access GPU utilization. Steps to reproduce the behavior: an Intel dGPU, such as the Arc A380 and the following relevant logs: This error should not happen, and should be able to read GPU utilization. ! As you can see, GPU utilization information is not being displayed. N.A. CC Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi It looks like there's an upstream issue tracking this: I'll look into this more to see how we can get this working, but I don't think this is something we can solve directly in the mangohud package. We'll need to use a separate NixOS module for since it'll require a security wrapper to enable . After creating a intel-gpu-tools module that sets the capabilities, I'm pretty sure we'll be able to get it working through something like this: but this would need to be used in addition to installing mangohud. Installing mangohud by itself wouldn't be enough.
Was able to get this working : Before | After ----------|--------- ! | ! Now just need to add this to a new module.


Steps to reproduce the behavior: blackbox-terminal blackbox uses vte with , this change probably broke it Please run and paste the result. but that's irrelevant as i'm trying to build the latest master. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project Description An actively maintained picom fork that adds extended animation support. Metadata homepage URL: source URL: license: mit, mpl-2.0 platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
One minute, I need to push the right branch
has been done, please react onto the pr so that it is marked as being more important. Have a very nice day
Thanks a lot! Added the reaction to the PR too.
Is this working? I have changed my picom configuration to use this package but none of the new options work.
It should be working, at least it does in my configuration, which includes the package before I ported it to nixpkgs. If you could state what problem you are having, that would be nice. Unfortunately I won't have much of a way to help you because the IC of my Linux laptop is fried, meaning that currently I have no way of being on Linux right now to test anything.


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.


If you have: During evaluation I get this error , pointing to the line Steps to reproduce the behavior: As described above I think this is because here The pairs are made using the , while here: It is trying to use the vhostName. So I think it should be Also, maybe this could be a problem as well, however I am not sure: I would submit a MR, but embarrassingly, I couldn't figure out how to test a patched nixpkgs lib in a flake without having my whole system rebuilt. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Broken by . Fixed by .


The patched version of Ardour in nixpkgs is not able to open VST2 audio plugins also installed from nixpkgs. All VST2 plugins are detected, but say they can’t be opened by Ardour. For example, having installed the ardour and lsp-plugins nixpkgs packages, the Ardour plugin manager shows the status “Error”: ! The error given for one of the VST2 plugins is: Steps to reproduce the behavior: Ardour and some VST2 plugins from nixpkgs (e.g. "ardour" and "lsp-plugins" packages) Ardour and scan for plugins The plugins are detected and can be used. I'm running NixOS 23.11 and installing these things declaratively with home-manager. i.e.: <!-- 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]:
I suspect is not actually a plugin, but a shared library used by the plugins in the same directory like which loads fine for me: Are you sure the actual plugins are affected? !
I tested with and and I was able to see both of those, but I'm able to reproduce other vst2 plugins (like LSP) not showing. Could it be that they're not in ardour's vst2 scan path? !
nixpkgs patches Ardour to find other plugin types, but I think i've to the plugin search path manually.
Hi guys, thanks for taking the time to look into this issue. You're right about the shared library not being a plugin - this was a red herring that was stopping me from understanding the problem. I just to my plugin search path and everything I was missing has now loaded in successfully. Thank you! To prevent other users from experiencing this problem (and possibly me if I change systems and forget this fix), can this path be to the list that the nixpkgs patch adds to ardour?


looking over broken python packages for ZHF and pixel-font-builder is missing a python module and needs a dependency relaxed. Steps to reproduce the behavior: *pixel-font-builder" pcffont not part of nixpkgs would add it but no longer a maintainer <!-- 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]:


Project description Utility to activate iPhones Metadata homepage URL: source URL: license: lgpl-2.1, GPL-3.0 platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Open a C++ project in vscode with the extension installed and see the following in the Extension Host output window: Steps to reproduce the behavior: a C++ project in vscode with the extension installed how autocompletion etc. features do not activate. to the output window and select the Extension Host and you will see the following: The extension should work ! Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm wondering if that should be 0555 instead of 0444.
Adding to got me around this particular issue but now I'm running into which should be resolved by moving to 1.20.5
Moving to 1.20.5 doesn't fix the startup issue
I'm replying to your comment here I can reproduce this with the following: Attached is the flake I end up with. My system packages are the following:
After changing the permission of this is what I get: If instead I run through manually I make some progress (it's looking for in my home directory) and it exits.
This is most likely


The following example in the python docs does not work since on the second line is supposed to be the interpreter and is for the packages: The fix is simply: System: 18.03pre118631. Nix version: nix-env (Nix) 1.11.15 Nixpkgs version: 18.03pre118631. Sandboxing enabled: false


When trying to launch whipper it instead fails with the following trace: Steps to reproduce the behavior: or any equivalent way of running the whipper program Clearly, I expect the program to execute without an error. I bisected the error and the bug was introduced in which bumped . <!-- 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]:
Note: Adding to double-wraps all executables, but allows to run successfully.
Also no double-wrapping.


a TUI-like CLI tool to manage the features of a Rust project Metadata homepage URL: source URL: license: mit platforms: everything that Rust supports Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


When configuring notifypush for nextcloud the service almost always fails the first time after rebooting the system and requires to be restarted in order to be started successfully. It seems the problem is that notifypush has not finished starting before nextcloud-notifypush-post-start is executed, resulting in a missing or not connected . Steps to reproduce the behavior: notifypush the system (un)lucky and watch nextcloud-notifypush.service` fail service (done automatically) The service starts successfully the first time. Relevant log lines: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I have noticed a similar behavior when the module it was introduced. But i was so far happy with the restart situation. I have played a bit with the situation. I am currently applying the following additional configs to my nextcloud. I think the problem is, that notify_push creates the used socket at start, and we are to early executing the ExecStartPost command to configure. When we let systemd take care for the socket, i could mitigate that and after that i had problems that my acme certificate reload was running in the mean time. After adding nginx-config-reload it was able to run on first try after reboot. You could check if that is also helping on your end and if yes we could check what make sense to use in the module.
I am not sure if this is a good idea since existing Unix sockets are on server startup (and shutdown), possibly interfering with the socket management of SystemD. I don't know why the connection succeeds after restart or when the socket provided by SystemD is replaced by another socket by notifypush, but I think a more robust way to implement this is to set which would delay the execution of until the server signals that it is ready. However something like this would require support by upstream, I could work on a pull request. Edit: After doing some testing it seems that for notifying SystemD to work notify_push has to be the main process of the service, which can be arranged easily by using in the start script.
Doesn't have the program call sdnotify for that to work? I did not find something like that on the code base. here the notify section claims something like that. Tho I fully agree that the socket is likely not a good idea when notifypush nukes the socket file. Edit: NVM you mentioned a upstream pr for such a function , which I seem to have over read when reading my mail notification.


Hey all, not sure which template is most appropriate for this, apologies if the format is incorrect. It looks like this package no longer exists upstream--the repository owner seems to have deleted or renamed their account. I'm not aware of any maintained forks of this project, so I think this package is completely dead, and should be removed from . Note: while searching for forks, I noted that 1Password appears to . Without access to the original package, I can't say for sure they are equivalent, but may be worth investigating for any affected users. Package name: Latest released version: GONE <!-- 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]:


A clear and concise description of what the bug is. Steps to reproduce the behavior: Mac Silicon, Utilizing with nix-darwin, i've the folllowing : always get qemu-system-aarch64 as qemu binary and then an aarch64 linux builder uname -a should give x86-64_linux Qemu binary program in () should not be forced to hostPlatform system for this linux builder case If applicable, add screenshots to help explain your problem. Add any other context about the problem here. Did not find any issues related to this qemu program choice.
I think the qemu binary is set correctly in the builders, in this file: I was also having this problem, and found this issue while looking into it. But I realized the result is being caused by these lines in nix-darwin: () That looks fine, but the builder package we're trying to use is also created using override! So the in nix-darwin is overriding the in nixpkgs, making the resulting package have the default hostPlatform. You can work around this by setting that value in your nix darwin config, like this: I've opened a pull request to make this work the way we expected it to: Thank you for this issue, it confirmed that I wasn't the only person having this problem, and led me to find the cause.
Thanks a lot !


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 /cc <!-- 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]:


Steps to reproduce the behavior: to the NixOS configuration. nixos-rebuild to build NixOS. According to the Nixpkgs search, there should be the packages python312Packages.journalwatch and python311Packages.journalwatch in the Nixpkgs unstable branch. I just checked the master branch and I haven't been able to find those. I could only find pkgs.journalwatch. That's fine, but then it means the journalwatch module needs to be updated. Perhaps this is related to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --I won't add the Metadata since I'm in the process of building NixOS, so the result would be incorrect anyway. I'm on Nixpkgs commit Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Breakage caused by . Please have a look at and let me know if that works.
Ran into this as well, the PR looks good and seems to fix the issue. Backport should land soon. Thank you all!


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


Unable to use Podman's quadlets feature for a user, since the service unit files are not generated by systemd. Steps to reproduce the behavior: a quadlet file in (say, ) . Systemd says that no unit files were found. Caddy service should have been generated and its status displayed. This issue is caused by not symlinking the provided by the package to . Does not occur at the system level, since is already symlinked to Fix: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Confirmed the quadlet systemd user generator is not found in /etc/systemd. I'm gonna take this one and try to come up with a fix in NixOS module.


luarocks exists that other luarocks packages can depend on. When trying to build a rockspec that depends on luarocks with , it fails. The entry in the generated luarocks config contains an entry for luarocks, but luarocks doesn't recognise it and tries to download the package instead. I have created a repository to reproduce it with: Run A workaround is to use to generate a expression for luarocks (), and to add that package to the 's instead of the package from nixpkgs. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for creating the test repo, it's helpful. I've looked at the generated LUAROCKSCONFIG and all looks good and I think luarocks just doesn't recognize the installed luarocks because of My first thought would have been to rename the current luarocks into a luarocksbootstrap and add a generated derivation, for which we could run the tests without the cyclic dependency luarocks -busted -luarocks. While this might be the best outcome longterm, I am looking into the quickfix which would be to generate the manifest for the current luarocks


Steps to reproduce the behavior: archivy Add any other context about the problem here. nixos 24.05, nixos-unstable at Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description Instrument your LLM app with decorators or low-level SDK and get detailed tracing/observability. Works with any LLM or framework <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit platforms: linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Steps to reproduce the behavior: radicale at quick glance I think they rereleased tarballs with more changes, files inside are from today Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Yeah, looks like upstream changed the release afterwards. I didn't even know you can do that on GitHub.
You can just delete the tag, create a new one with the same name and do a force push. Some projects do this, some don't.
I suggest any that do be removed from Nixpkgs. It's unacceptable.
Can someone revert for now?


Steps to reproduce the behavior: The src is: We tried to use from nixpkgs in , but that made nix-build . -A fail. I guess that happened due to one of the commits between and (which is the latest commit on ) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description <!-- Describe the project a little: -- alternative for GNOME (I guess) Metadata homepage URL: source URL: license: gpl3Only platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Sometime between 23.11 and now, the binary broke due to a linking issue. Steps to reproduce the behavior:
fixes it of course, but I don't see an obvious less brutal approach.
adding to the works for me.
Good point, somehow thought this was already the case. PR up.


(///) packaged in does not detect Muse Sounds Manager. The Muse Sounds profile is greyed out and cannot be used; leaving only MuseScore Basic available to use. Steps to reproduce the behavior: from (at the time of updating, version ) the unofficially packaged ) flake. MuseScore either from the desktop entry or via in a terminal, visit in the top bar, to check for available playback sounds to use. The Muse Sounds profile should be available to use and not greyed out. ! I have acknowledged the fact that although the mentioned Muse Sounds Manager package is unofficially packaged, the package works with the AppImage Version of MuseScore (packaged officially ), so I don't think this is the problem with the Muse Sounds Manager flake. Below is the screenshot of what the Playback Setup window should look like, taken from the AppImage version while opening the same score as the previous screenshot. ! I have tried reinstalling Muse Sounds Manager itself and reinstalling each Muse Sounds, but the issue persists. My entire system configuration files are . <!-- 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]:
Sorry, miss-clicked submitting the issue without adding any information. It'll be updated soon and reopened later.
Hey I'm sorry but I can't reproduce your issue. I Ran and downloaded an example font, and with both 4.3.0 and 4.3.1 I get: ! Before I downloaded the sound fonts I also had that button grayed out. Maybe you simply need to check again?
Thank you for responding. The issue persists after I've tried and and everything else (reinstalling MuseScore, Muse Sounds Manager, reinstalling all combinations of Muse Sounds) again to confirm that this is not an isolated incident. Additionally, I've compared the logs of both the AppImage version and the version. Most of both outputs are identical (apart from some timestamp-dependent data), but these lines only show up on the version: If necessary, please let me know how I can provide any more information.
Nice! Perhaps it is related to specific sound files you downloaded with that I didn't? Perhaps can you share all those? I have only this one named .
I've tried and downloaded all Muse Sounds from the beginning again for another time just for good measure. Here's an exact order of what I've tried (only one at a time, uninstalling all other Muse Sounds) and the issue still persists: Keys Brass Guitars Vol. 1 Choir Harp Percussion Strings Woodwinds So, all of the Muse Sounds available. The terminal logs print out the same error message on the version. I've also tried each of these with the AppImage version and I can confirm all of these are recognised with no issues. Is this in some ways related to how ? (This is an uneducated guess from me noticing logs mentioning the dynamic library )
Hey and sorry it took me a while to get back to this. It'd be nice to get your approval upon the 4.3.2 version bump (haven't even built it yet): So I tried to download all of the sounds mentioned above, and still I can see the muse sounds profile... I don't know what else I can suggest to debug this :/ Wait where do you see these lines? I don't see them in either muse-sounds-manager's logs nor in Musescore's ... Log of muse-sounds-manager-nix : And log of Musescore:
It's all good :) I'm just happy someone is even looking into this, to begin with. As to the 4.3.2 version bump, what do you need my approval of specifically? I'm sorry, I'm still very unfamiliar with the Nix ecosystem as a whole. Although, I have built the 4.3.2 on my machine and tried , everything seems to work (I've tried playing some tracks, editing them, etc), including the Muse Sounds. ! Additionally, I've done some more debugging: It seems like: running in the terminal (tested with + ) doing and then in the terminal (tested with & ) launching from the Desktop Entry all had the issue of Muse Sounds not being available to use. However, doing: (in ) / (in ) , into the output directory, then do all have Muse Sounds available to use. So this seems to be more of an issue with my shell environment somehow, and I honestly have no clue why this is the case, or where to start looking. That's a bummer. I mean, I guess I could always just use the AppImage version; It's not a big deal. Thank you for looking into it at least. Honestly, it could just be something arbitrary only in my machine in particular. Sorry, I should've clarified: The logs I sent earlier are from MuseScore (I just ran in the terminal). I didn't share Muse Sounds Manager's logs since nothing seems out of place there. Here's the full logs of me only running in the terminal and then closing the MuseScore window shortly afterwards: As you can see, line 9~12 showed the error I mentioned earlier. Again, thank you for taking your time looking into this.
Indeed this line seems suspicious.. And when you run version 4.3.2 you don't see it? I didn't find that line in my logs as well...
Yes, all other mentioned methods with Muse Sounds available don't have those errors in the logs.
It's weird because returns nothing... There is: Which may be related.
Edit: I was mistaken, setting the still doesn't detect Muse Sounds.
Yes it surprised you wrote initially it worked for you. We are on NixOS after all :). I'm not sure if you are subscribed to that issue or not, but I asked them about the source of .
BTW today I experienced crashing for me, and I checked the backtrace () and this is what I found: Interestingly: So indeed this issue is related to external shared objects that are not compatible with NixOS. I'm still a bit confused as to why in your case it doesn't necessarily crash, and instead it silently fails and you don't see the muse sounds... It'd be interesting to try to that file before you run ... In anycase, this should also be discussed with .
Hello, I've done some additional testing. It's not much, but I still want to tell you what I've found. It turns out these only work with that one MuseScore instance. From that instance, if I do or , it will always fail to load the dynamic library. I haven't yet figured out how to launch the new instance and have the dynamic library properly loaded. So this must be something weird about my variables, some directory mismatch, or something else. I've already sent my here, but in case you haven't taken a look, I have in it (which in turn makes return ), in case there are some hard-coded paths that don't respect this nix setting and is messing up with the dynamic library lookup. Just bringing it up since there have been some Nix packages not respecting that setting and causing issues with me in the past.
Hey did you end up finding a solution to this? I'm experiencing the exact same thing, and this thread is the only place mentioning these issues
Unfortunately, no, I haven't. Whenever I need to use MuseScore with MuseSounds (which is, all of the time), I launch MuseScore by doing in the terminal, which is one of the workarounds I've stated which have MuseSounds working.
Alright, thanks! Yeah I've seen your comment above, and to my surprise did indeed work. Maybe I'll just overwrite the mscore.desktop file with this command for now (Btw, thanks for the debugging effort you've put tinto this)
is not an issue due to the way library lookup works on Linux. Since is an optional dependency, it is loaded with (in via ), and says in particular that dependencies of such libraries are looked up in directories of the executable that calls . is a C++ application, so it also depends on and its contains a /nix/store directory with , and when it loads , the latter uses the same from the nix store. You can run to confirm that it has and that its contains the directory where it is located ()
The reason , etc. do not load is that the latter contains a shady function that prevents this library from loading when the calling process name () does not end with or . When you run MuseScore in the console from PATH, the process name is simply (without ), and the library declines to load. Similarly when you open a new score from MuseScore, it launches another instance of the program with the name which also does not end with .
the f. Amazing job figuring that out! (And also thanks for the MuseSounds nixpkgs PR )
Indeed this is a very impressive investigation and conclusion . I'm a bit confused though - whether we use a wrapper or not shouldn't make a difference right? Because the wrapper script (whether it is or ) always set to right - hence the shady function will return , at least as a of right? I wonder whether we should perform a to an absolute path in to improve 's experience described here.
I have already made a fix and will make a PR out of it very soon. MuseScore's argv0 will always end with regardless of the way it is launched, so can stay the same. (In my experience during system upgrades .desktop files are more convenient without absolute paths.)
You are right about the initial launch of MuseScore, but when you use File -New, it launches another copy of MuseScore, and it does this (as is common on Linux) by executing the target of , which is and this becomes of the new instance of MuseScore.
That's my experience as well. Ah wow, now I understand! Thanks. It means the patch will be much more involved... Good luck with that! I wonder why upstream decided to add that "check argv[0]` in the first place. The 4.4.2 release just came out, and the build locally seem to go on OK, so I just opened - marked as a draft, waiting for your magic patch.
The API of is easy to learn from , which makes it technically simple to use MuseSampler without MuseScore. For example, someone writing a VST plugin could just load and use it as a virtual instrument player in any DAW, without MuseScore. I guess that Muse Sounds authors wanted it to be tied to MuseScore, so they made it fail to initialize when loaded into a program with a different name. This is particularly clever against VSTs since a VST can't change argv0 - the user of such a plugin would have to rename their DAW to !
Wow, thank you so much for the debugging efforts you did! I'm available to do some testing if you need any.
Thanks! You are welcome to test


Project description for python! <!-- Describe the project a little: --It is built in reference with offical except it's color quantization part, which is based on thanks to . Metadata homepage URL: source URL: license: mit platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


When bulding an lxc template with and the , the ping binary does not work as the not root user, giving: Steps to reproduce the behavior: my config repo: the nix-secrets input (private repo). `nix build .#proxmox the resulting tarball and upload to proxmox as an lxc template a container based on the template in (without nix-secrets repo, password is 'nixos') and attempt to run ping. The ping binary successfully pings something. the Home-manager systemd service also fails, but that might be a separate bug, reported Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
on NixOS 22.11: On NixOS 24.05: Seems to have been broken by I'll spend some time over the weekend to see what the best way to solve this issue is.


Package name: gruvbox-gtk-theme Latest released version: unstable-2024-06-12 <!-- Search your package here: --- Current version on the unstable channel: unstable-2023-05-28 Current version on the stable/release channel: unstable-2023-05-28 <!-- 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]:


Decoders fail to load due to . Steps to reproduce the behavior: Working Module Imports (no ) Working decoders Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can you check if the above PR fixes the issue. I'm not able to test it right now as I don't have access to a DSLogic device ATM.
I'm unable to test the PR ATM, but the issue didn't require any device to be attached. Just install and run DSView as per bug report.
Ok just running and playing around did work for me after the update.
Hey, I checked this on my box, and I don't seem to be able to reproduce this issue, decoders seem to work for me when trying the demo device.


btrfs-assistant failed to use in nix-shell Steps to reproduce the behavior: A clear and concise description of what you expected to happen. nix-shell should success <!-- 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]:
I fixed the nix-shell -p error but the application doesn't run properly. Looking into if we need to do some env variable nonsense because of the way the application works.


Steps to reproduce the behavior: Discovered via the Nixpkgs LLVM Workspace project. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --No maintainers, CC last person who touched Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Steps to reproduce the behavior: Add any other context about the problem here. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Maybe we should just wait and see whether 2024.02 also has the same problem (that should be around the corner, see ) For now rolling back to to get unstuck.
I'm skeptical about IDEA 2024.2 would use JRE 21, as in the following comment From https://intellij-


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


The package is broken, , because it fails during on Darwin. I am uncertain if this is something that has to be fixed in , or can it be worked around in nixpkgs? Steps to reproduce the behavior: Build on macOS <!-- 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]:
can you help out here?


There is Bitwig1 and Bitwig2. I for example have only a license for Bitwig1. And I will not pay frequently for features I don't use (because I'm not a professional musican). Right now I use the overrideAttrs to install bitwig1, but it would be smarter to provide an older version as well (most likely there will be a bitwig3 someday). I could create a pull-request, just wanted to open a quick discussion first, because I'm new to NixOs and maybe there is already a very smart thing that makes live much simpler, which I'm not aware.
See . I think we shouldn't distribute paid updates for proprietary software under the same attribute without a way to opt out (other than rollback), this heavily breaks reverse compatibility. I think that should point to the latest version, with and pointing to specific major versions. Derivation for 2.x branch may override 1.x, since it has same dependencies and layout, the only difference is additional dependency on :


The package for the Ares emulator doesn't seem to include Vulkan packages so it will return if you try to run a Nintendo 64 game. Other cores that don't use Vulkan are unaffected Steps to reproduce the behavior: Ares N64 game error in console glitched or black screen The game works ! see similar issue: Ares issue before I realized it was likely NixOS: GPU: RX 6800 Driver install setup: <!-- 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]:


Package name: quickemu Latest released version: 4.9.5 <!-- Search your package here: --- Current version on the unstable channel: 4.9.4 Current version on the stable/release channel: 4.9.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. --fedx- Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Specs-nvim does not work in Neovim 0.10 and the author has not updated the upstream version. The derivation should point to the updated fork instead: Steps to reproduce the behavior: specs-nvim with Neovim 0.10 specs-nvim errors Should I have used the out-of-date packaging report issue template instead? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
no pb for me. Feel free to submit a PR. Pinging as he might know better.
What does no pb mean? I'll make a PR
I guess that it means "go for it, let's switch to the fork".


Package name: uutils-coreutils Latest released version: 0.0.27 <!-- Search your package here: --- Current version on the unstable channel: 0.0.25 Current version on the stable/release channel: 0.0.25 <!-- 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]:


Xpra supports forwarding invocations from the server to the client. The Xpra client defaults to hardcoding as the command to invoke on the client, which does not exist in NixOS. This bug does not impact hosts other than NixOS. Steps to reproduce the behavior: somehow. The Xpra client should invoke the local . N/A. This could be fixed by setting the open command to just , but it might match the intent better to change it to something like perhaps. Presumably, the point of doing it this way is to avoid any other copies of that might appear on the , e.g. Xpra's own. I suppose we can't really rely on to exist: even if we could on NixOS, we can't on other Linux distributions running Nix, where might make more sense. It seems to me that the best compromise, then, is to hardcode a path to copy of and users can override this using the option if needed. The open command that Xpra uses is configurable on the client-side, but the default is set as a platform-specific variable. On Linux, it is set in . Because there are separate values for both Windows and Darwin hosts, patching the value to shouldn't ever break them (but of course it should still be a Linux-specific patch, otherwise it unnecessarily brings into the closure.) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


The src URL () for Azure Data Studio redirects to latest version (1.48.1), not the specified version (1.44.1), leading to build failure due to hash mismatch. i.e. redirects to . Steps to reproduce the behavior: Specified version of Azure Data Studio should be downloaded, verified and installed. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description goread is an RSS/Atom feed reader for your terminal. It allows you to categorize and follow feeds and read articles right in the terminal. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Klee installation returns the following error: Steps to reproduce the behavior: <!-- 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]:
Thanks for the report; looking into it.
Looks like a STP issue on master/unstable; any ideas?
KLEE works on 24.05, try that in the meantime.
See also: , , and others. Seems like this is treewide.
It looks like there's an update to ; I'll bump it after gets merged but those two changes should fix klee.


fails: see: cc: n/a <!-- 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]:
(Fixed the title, my bad)
The current () tailscale builds fine for me on , but I gave it a try to be more "correct" anyway. I attempted to change to the following as a fix: However I seem to get the following error: I also tried running itself in the just to see what happens, and got an exec format error, presumably that's the cause of not having a completion in the first place.


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


Flexget is not building on python3.12 on NixOS Unstable since nose 1.3.7 does not run on python 3.12 According to flexget website only pything versions 3.7 to 3.11 are supported: Steps to reproduce the behavior: to nixos unstable to install flex A clear and concise description of what you expected to happen. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


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


Steps to reproduce the behavior: with One test is failing: only the relevant part Add any other context about the problem here. (note, I've set the project to the geospatial team, which should be enough to have it in the radar maybe?) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm currently bisecting to confirm my intuition that it is a dependency version change that is triggering this failure.
The first bad commit could be any of: Probably an upstream issue?


Rendering a project in Kdenlive with default rendering settings leads to the following error: Steps to reproduce the behavior: ( is the latest revision of at the moment of writing this) any clip to the timeline (for example, drag in an image) "Render..." "Render to File" You might need to use as your desktop manager to reproduce this issue. There is claiming that this crash doesn't happen on Plasma 6. I am using Plasma 5, but I am currently unable to verify if Plasma 6 would fix this issue (Plasma 6 is broken for me for unrelated reasons). Render should succeed. See issue for the previous instance of this problem. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are you using the kdenlive matching to your desktop? Edit: nope, you are using the plasma 6 package. You want to use plasma5Packages.kdenlive.
is plasma6? Wow, that's quite a foot gun. Shouldn't it be called ? Also, fails with the same error.
It really should not matter, and will (once is entirely gone) be whatever versions upstream ships.
it seems that the problem either wasn't fixed or has resurfaced again? I was able to reproduce the exact same error with and (where is the latest revision of at the moment of writing this)
Please try again after the staging-next merge (which should make its way to unstable in a few hours).
I will. Could you explain why staging-next is relevant in this case, though? I am just curious. I checked using and in the github UI directly, and it seems that the changes from should be already present in revision .
staging-next reshuffles protobuf versions again.
I wasn't sure which staging-next merge you were originally talking about, so I tried the same thing with commits (current nixos-unstable), (current staging-next) and (current master) and I am still getting the same error. Can you reopen this issue, or should I open a new one?
Hm. Actually, I think that I figured out, what the problem is. It seems that actually saves some paths in . For example, my had the following lines: Deleting the line fixes the issue, but then adds it back again with the new path, so it will almost certainly eventually break again. I am honestly not sure, why does do this, but we should probably either patch this behavior or report it upstream.
That sounds very wrong because you have defaults from two different kdenlive versions in there.
I can tell you that I've never touched prior to this debugging session. I didn't even know it existed. Those lines seem to be automatically populated on demand. Most likely, these lines were simply generated at different times, and so they picked up different paths to the "current" version of . Also, the fact that these paths are different from each other is mostly irrelevant in this case. The real problem is that they are cached once and aren't updated when a different version of is used.


Steps to reproduce the behavior: (or try building pkgsLLVM.llvmPackages_git.compiler-rt) It seems like useLLVM causes the sanitizers to be disabled, not sure why this is the case as LLVM can rebuild itself with sanitizers enabled (outside of nixpkgs). See Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Ok, removing those useLLVM checks resulted in this:
cc may be helpful.
Unable to reproduce this.
Huh. I just ran into it with the new llvmPackages_git 19 -20 update in nixpkgs Hopefully the above nix file will be allow someone to reproduce it.
That seems to still produce the same result.
Turns out this is related to .
CC since this is related to sanitizers.
It's reproducible by building at version : Building version works fine:
Interesting, I wasn't using no-libc I think but I was doing it under pkgsLLVM and on aarch64-linux. That version doesn't look right.
Really? It seems to be the . Also, I have good news! Following the , I tried adding to , and it works:
Yeah, that's two weeks ago. Git is updated every week on Sunday. The PR for this week's update worked (although it only tests LLVM to clang). Interesting, I can get on this tonight.


It would be nice if generated and options (only ). Processors without microcode update might run with misbehaving flashed microcode: /cc
Do you mean like setting it to or just mentioning it? It's a good thing for sure to have working hardware as opposed to not working, but OTOH it pulls non free code...
Of course setting it to true (actually to ), mentioning it would have no effect. First, already pulls in literal unfree code, e.g. Wi-Fi drivers on MacBook Air 6,x, not even redistributable. Second, non-free code is already running on Intel processors, I don't see any difference whether it's flashed or not (I know this is controversial). Third, for purposes of Nixpkgs, is free. And of course the kernel contains a whole lot of firmware blobs.
Strongly disagree here as its an equivalent of setting = true; thus will taint every installation by default, which is a reverse policy of the current nixos from optin to optout. That said, being complete new user, I have myself figured and found these options myself. My system booted without them likewise fine. In general, AMD patches CPUs with AGEISA BIOS updates, so does Intel - however these updates are optional and up to the user. This is should be mentioned on a) Installation page b) NIxos wiki - not be made default option, because this action is in conflict with policy.
I disagree that this is equivalent. CPU comes preflashed with microcode, BIOS comes with updated microcode for the processor to boot correctly (microcode that comes with CPU is very buggy and usually can't go through boot sequence correctly). It's not clear how it would add to the problem if we were to load an up-to-date microcode image. This is equivalent to shipping firmware to users that haven't set flag, which is current NixOS policy. Intel microcode is freely redistributable AFAIK.
The default state for these two switches is very clearly "disabled", plus they have no affect on non-AMD/intel CPUs. Flipping the switch in hardware-, is basically flipping the default state in the backstage, which is much worse than setting the defaults to "enabled", as it creates distrust and inconsistency cases. Further, firmware updates can cause real issues, not only solve them. It is irresponsible to think that they only solve issues. AMD AGEISA updates on 785G on has actually been broken for over a year for me, refusing to react to USB events on boot until I manually bypassed the tier 1&2 support (which is hell of a job for Linux user) to get to actual support for testing. About Intel, I have only encountered issues with gen3 PCIe cards in Intel motherboard for 2nd gen Core CPUs, but fixing this also required a year of waiting and UEFI reflash. Also speaking as an owner of HP() and Epson(sx525wd) printers - updating ucode actually caused hardware reflash and made legally purchased cartridges worthless. I am yet to encounter a CPU that can't pass boot sequence due to buggy ucode, but I doubt hot-loading it on OS stage would fix it, because it needs first to get to this stage. However I can clearly imagine the unpredictability if these switches are properly enabled.
Microcode is essentially a firmware for the CPU. NixOS, more specifically, the Linux kernel, will load firmwares for any device with support for that without asking the user. Loading microcode updates does not require a policy change, if anything, this would make the policy more consistent across the board. On a tangent, I don't understand why anyone would tolerate a blob flashed on CPU, and in BIOS, but would not tolerate the same blob being loaded by the kernel. That can be said about any software. Usually, the opposite is true. What I mean is that every BIOS except Libreboot contains microcode blobs that it loads onto the processor early in the boot sequence. Without that blob, boot sequence will most likely fail somewhere along the way. That's the reason why Libreboot doesn't support modern Intel/AMD CPUs, and why there is Coreboot/Libreboot split in the first place.
You are mixing very different cases into one bottle. Some hardware requires ucode to be loaded to function and won't function without. Some hardware has optional ucode updates. For this hardware, some classes load firmware update and then flash themselves - some lock the possibility to install previous revision, and some classes load the ucode as temporary override (which is case with AMD/Intel). Some hardware has open firmware (sources), but majority does not offer source. In essence, ucode is a blackbox and live-updating ucode is unpredictable black box. For some devices, ucode loading is a must, for others its optional. I suggest that we limit ourselves to specific case of Intel/AMD ucode, for which ucode updates are optional and crucial updates are applied only via hardware flashing. I am pretty sure that the reason why Libreboot supports less hardware has to do purely with acceptance criteria for how tainted ("blackboxed") the firmware is, and that both support little of x86, because Intel refused to provide specifications and AMD was open to some extent, but then closed up the AGESA after Phenom II because they most possibly implemented TPM in firmware(fTPM). About EULA-d + encrypted software, we are talking about closed-source hardware. For manufacturers of such software, surely opposite is true and the updates are usually used to keep their policy consistent and enforced, for users it means giving up and restricting all rights. That said, I found those options myself easily as a new user (yet my hardware functioned without issues without them) and I see a problem if they default to one value, but change "automatically" and unnoticed at run-time. Either way, this option should be documented better - and this includes places where its flipped.
It's not clear what difference does it make. Say, from freedom perspective, it would not be OK to use Windows even if I were to ignore any updates for it. If we ship updated microcode, which includes security fixes foremost, how would that taint installs any more than they currently are, with in-kernel blobs and such?
It has to do with blobs for the most part. See:
It replaces non-free code with a more up2date non-free code. Given Meltdown and Spectre this should be the default. Especially since it would be generated at installation time. Accompanied with the right comment, users who really want to have outdated CPUs will be notified and can delete one line. (well two with the comment).
I would like this to default to (microcode essentially is firmware). isn't supposed to be edited, it should just use so that user can override it in their config.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
still think this should be done, as new users probably don't know this option exists at all and that you have to enable it by yourself in NixOS. With concerns on, this should at least be generated as commented out, with a hint "while you will probably want this, note that it is unfree software".
I marked this as stale due to inactivity. →
Why is this no longer in discussion? As someone new to the NixOS universe and coming from Ubuntu I wasn't aware that I had to explicitely include this in my hardware configuration on NixOS until I stumbled across other people's configuration files. I definitely think it should at least be prominently featured in the installation manual or even better be enabled by default, as mentioned.
One way or another, needs to be enabled by default. These updates fix security issues, there are probably a lot of NixOS users now that don't even know that they're running insecure microcode. See also the discussion in
I've never replied to the first comment! While I still support the open hardware movement (and thus free software firmware) I also believe that having QEMU misbehave because of a missing update is not really a good default option. If the user is concerned about the microcode updates or about managing security at this level then they will probably read the auto-generated configuration and immediately spot an and will comment it out :-) So thanks for the PR, I can't review because I don't know perl :-p


Steps to reproduce the behavior: Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Package name: nuclear Latest released version: 0.6.31 Current version on the unstable channel: 0.6.30 Current version on the stable/release channel: 0.6.30 <!-- 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]:
Made a PR, would appreciate it if you tested it - I don't use nuclear very often at the moment.


Project description Library to build personalized AI powered by what you've seen, said, or heard. Works with Ollama. Alternative to Open. Secure. You own your data. Rust. Has both CLI and desktop app. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, windows
I am somewhat interested in this package and started a PR but I am super busy these days to thoroughly test the package. If anyone can do that, that would be awesome.


404 when trying to install. Version is out of date on both stable / unstable. Current version is 1.3.5 aka <


Steps to reproduce the behavior: Discovered by <!-- 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]:


Ollama is a big project and I think having a nice UI in the stable repos would make nix even better. I can help with the PR but I am new to nix and don't really understand the git workflow and all Pinging the package maintainer: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Current master is broken for (see ). However, I don’t think that should be a problem while backporting to , as .
Backport PR for 0.2.4:
To track the progress of backporting to latest , see:
I love this, thanks!!


Package . This seems to be interesting, we should package it. This issue is a friendly reminder for myself to package this some time. I do not feel offended if someone wants to do this, though!
oh wow, thanks!
Oh! I thought was the one who filed this request haha, my mistake! That's why I included as maintainer originally.... I thought there was a sudden change of heart! :laughing: Anyway, no problem GLHF. (and it looks like 1.0.2 is out now, if there's a compelling reason to update LMK otherwise I was going to see if they stabilized a bit before updating)


After merging today, no longer builds. Not sure how to fix, :(. Building against parent commit of merge (not from staging), , produces working pandoc. Hydra log:
Looks like changing to : But I'm not at all sure that's the correct sort of dependency.


Hi there! I’m sorry to bother you with a ping. We realized that in the form of . All of our Nix expressions are meant to be MIT‐licensed, so this is a big problem, especially as packages using / may count as derivative works, potentially jeopardizing the licence status of Nixpkgs as a whole. We would therefore like to get permission from all contributors to this code to relicense their changes under the MIT license used for Nixpkgs. If you have any questions or concerns about this, please ask them in so that this issue can purely be for tracking the sign‐offs we’ve received. To agree to the relicensing, please reply to this issue with the following verbatim text: [x] [x] [x] [x] [x] [x] (confirmed via email) [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [ ] [x] [x] [ ] (GitHub account is gone, although as this was just a treewide removal with no other changes it’s unlikely to be copyrightable) [x] Authors of unmerged pull requests in the old repository (just in case we ever take code from them): [x] [x] [ ] [x] [ ] [x] [x] [x] (I have not checked for unmerged PRs to this part of Nixpkgs yet because it’s a pain.)
Apparently I can only ping so many people at once; please look at the original issue text, sorry!
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs. PS: nice catch and thanks for taking care of it
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs. Like, sure, we still use it in our toolchain, and this move is very nice.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , and the pkgs/development/tools/yarn2nix-moretea directory of the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs or any other OSI considered free software license. IIRC if we get everyone else on the list, then will be fine.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
Just another gentle ping; if you could check the original post at respond as requested it’d help us resolve this licensing issue.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
While it wouldn't hurt to get approval from the last 4 people, I don't think we need that to move ahead: gebner only authored , a minimal change that I don't think would be copyrightable egasismus only authored , another minimal change that I don't think would be copyrightable chawki008 only authored a PR that was never merged: eqyiel also only authored a PR that was never merged:
Yeah, I agree those changes aren’t copyrightable. I did email the authors of them but I’ll proceed with opening a PR to do the relicensing now.
I agree to license all of my past contributions to , , and the pkgs/development/tools/yarn2nix-moretea directory of under the MIT license used by Nixpkgs.
Thanks so much to everyone for helping get this done so quickly, and for your contributions to the Nixpkgs ecosystem


Hello, please find below a bug report about the Nix package qdidgidoc: I can not sign any more since the 24.5 update. Failed to sign container. Please check the access to signing services and network settings. Failed to sign container. Failed to connect to host: 'dd-' DECODER routines:0 error:1E08010C:DECODER routines::unsupported BIO routines:0 error::BIO routines::system lib I also checked if I am able to authenticate with https://web- . Both, authentication and singing works. For completeness, here my diagnostics output: Locale: English / enUS.UTF-8 Application version: 4.5.1.0 (64 bit) OS: NixOS 24.05 (Uakari) (x8664/x8664) CPU: AMD Ryzen 5 PRO 4650U with Radeon Graphics Kernel: Linux 6.6.44 -NixOS SMP PREEMPTDYNAMIC Sat Aug 3 06:54:42 UTC 2024 x8664 Libraries: QT (5.15.14) OpenSSL build (OpenSSL 3.0.14 4 Jun 2024) OpenSSL current (OpenSSL 3.0.14 4 Jun 2024) Arguments: qdigidoc4 Library paths: /run/wrappers/lib/qt- 15.14/plugins; 15.14/plugins;/var/lib/flatpak/exports/lib/qt- 15.14/plugins; 15.14/plugins;/nix/profile/lib/qt- 15.14/plugins; 15.14/plugins;/etc/profiles/per-user/getreu/lib/qt- 15.14/plugins;/nix/var/nix/profiles/default/lib/qt- 15.14/plugins;/run/current-system/sw/lib/qt- 15.14/plugins;/nix/store/h8m7pcd6d20jsx7hn81rsgkq0h884893-qtwayland- 15.14-bin/lib/qt- 15.14/plugins;/nix/store/vc9wklk5w3cskkymp52g7js83my4d9ch-qttools- 15.14-bin/lib/qt- 15.14/plugins;/nix/store/plix80gx31963j2qpsws7rid1gfr6cyn- qtdeclarative-5.15.14-bin/lib/qt- 15.14/plugins;/nix/store/h32d5q8ngcy68nddbw5vja3r316s20p3-qtsvg- 15.14-bin/lib/qt- 15.14/plugins;/nix/store/fbddznz5ln765jbl2i2mfnf8h7rkkmd9-qtbase- 15.14-bin/lib/qt- 15.14/plugins;/nix/store/h4li58h9pni11wigz8xldad9kgzc0q3c-qdigidoc- 1/bin URLs: CONFIGURL: SID-PROXY-URL: https://dd- SIDV2-PROXY-URL: https://dd- SID-SK-URL: https://dd- SIDV2-SK-URL: https://dd- MID-PROXY-URL: https://dd- MID-SK-URL: https://dd- RPUUID: is set by default TSLURL: TSAURL: http://dd- SIVAURL: CDOC2: CDOC2-DEFAULT: false CDOC2-USE-KEYSERVER: true CDOC2-DEFAULT-KEYSERVER: ria-test TSL signing certs: Patrick Kremer (Signature) European Commission European Commission JEROEN ARNOLD L RATHE APOSTOLOS APLADAS CONSTANTIN-ADRIAN CROITORU TSL cache: (65) eu-lotl-pivot- (335) eu-lotl-pivot- (341) eu- (343) g0xdp6w34ric1mdh8g7r0v8h85idkcg1-eu-lotl-pivot- (300) Central Configuration: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I can reproduce. The "Signing" animation is shown for a while, and then an error too: The error message mentions not being reachable: ! This hostname does not even have a DNS record. I spotted changing the "Default TSA URL". Maybe they updated the URL in some places, but forgot updating elsewhere? I found this URL in my qdigidoc settings too: ! Changing it to the new URL unfortunately also didn't help, as it doesn't like the Digicert certificate. Maybe unrelated, maybe not - I also see a in my logs. This looks like an issue in the application itself / some config shipped somewhere, but nothing NixOS-specific. I propose opening an issue upstream in qdigidoc, maybe linking to here for context.
I tried manually bumping , and I tried using from . It mentions a signature to be invalid: Opened an issue upstream:
I got a link to , mentioning a workaround. However it looks like the libdigidocpp changes linked there are not a sufficient fix, so I cannot patch this in nixpkgs, and it for now requires each user to manually set that address and import certificates.
As I understand now fixes this issue with the related commit: . Do you consider a patch release?
Unless I'm missing something, is the only relevant change for us from this commit (which sets the flag). The patch doesn't apply, but IIRC I tried setting this manually via and it didn't fix things for me back then. I can try again tomorrow or so, re-rolling that patch and trying to sign again with a fresh profile. Yes, absolutely, if there's a patch we can apply to fix this for nixpkgs users, at least when starting with empty state I'd like to do it.
I did apply the TSA_URL change in , and it seems this was enough to get signing to work. PR is up at , please test and report back there.


Project description A modern top command that charts system metrics like CPU load, network IO, etc in the terminal. Metadata homepage URL: n/a source URL: license: mit platforms: darwin (amd64 and arm64), untested on other platforms Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Not too long ago was updated to have as its dependency. However both python packages have a , so the created from can't successfully build. Steps to reproduce the behavior: to build error: Not exactly sure what should be done, since I'm not familiar with the cli tools. As a workaround you can probably do (listed in meta.maintainers) (author of the that the dependency) <!-- 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]:


Package name: tailscale Latest released version: 1.72.0 <!-- Search your package here: --- Current version on the unstable channel: 1.70.0 Current version on the stable/release channel: 1.66.4 <!-- 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


Steps to reproduce the behavior: X Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
see


Getting an error trying to build grpcio 1.7.3 on darwin make: Circular /private/var/folders/4k/jpntp1hn6b7c9ymh7v044b9h0000gn/T/nix-build-python2.7-grpcio- <- /private/var/folders/4k/jpntp1hn6b7c9ymh7v044b9h0000gn/T/nix-build-python2.7-grpcio- dependency dropped. ar: illegal option -- / usage: ar -d [-TLsv] archive file ... ar -m [-TLsv] archive file ... ar -m [-abiTLsv] position archive file ... ar -p [-TLsv] archive [file ...] ar -q [-cTLsv] archive file ... ar -r [-cuTLsv] archive file ... ar -r [-abciuTLsv] position archive file ... ar -t [-TLsv] archive [file ...] ar -x [-ouTLsv] archive [file ...] make: * [Makefile:8459: /private/var/folders/4k/jpntp1hn6b7c9ymh7v044b9h0000gn/T/nix-build-python2.7-grpcio-] Error 1 nix-shell system: host os: multi-user?: sandbox: version: channels(joestein): nixpkgs:
Try:
Thanks that worked to get past the AR error, fighting another error now with libtool but progressing along again. Thanks!!!
This derivation works now


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


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


Steps to reproduce the behavior: dvc another dvc hash error, i dont know why <!-- 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]:


First failing build (4.9.76, but not always): Latest (4.9.77): Looking through the changes for any obvious culprits...
bisected to (as the first "bad commit"). cc
Reverting the commit on master fixes the build, but need to replace with to at least fix evaluation on cross. Since doesn't seem to build on cross (at least not on any architectures I've tried) I can't tell if this "works", but would be good to fix this on non-cross regardless.
See corresponding PR, this has been handled. Thanks!


Project description <!-- Describe the project a little: --Syntax Tree Surfer is a plugin for Neovim that helps you surf through your document and move elements around using the nvim-treesitter API. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


is currently using this command creates the temporary directory inside the current working directory instead of in . This can cause the generated directory to be included in the final package, as I'm assuming accidentally picked it up. I encountered this while working on and The temporary directory is not included in the output use use (output is of the format ) note: this isn't really used across nixpkgs use something else <!-- 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 program described by this man page is not available in master. ag ipvsadm
Poked at this, looks like it needs which because it was old and krufty even back then (note the patches required). That seems like a bit of a show-stopper, unfortunately.
Thanks! Is there a replacement for that I am missing? is still a part of the Linux kernel.
Enjoy! LMK if you're able to actual test it or know how to employ the tools :+1:.
I plan to do that tomorrow. I hope the tools will tell me the crucial information I need to make it work.
This works great and should be merged. It told me something unexpected, but that's good.


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


Steps to reproduce the behavior: -rebuild test on settings.datadir = "/mnt/garage0"; resolves fine Tested on nixos24.05 but code of the module is unchanged in nixos_unstable. I'm using flakes as well Please run and paste the result.
Looks like doesn't apply, maybe should tinker a bit on my own
It looks like the option type was adjusted, but not the other code in the module that checks that value. Shouldn't be too hard to fix.


Steps to reproduce the behavior: try to install/build the package using nix-shell or nixos the Domain is no longer configured. Teamspeak Download Pages redirects to this place: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
You might want to check out
Not merged yet
As a workaround, until this is fixed in nixpkgs: The file is still available at the Internet Archive. You can fetch it from there and write it into the store, with something like this:


cc system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs:
Thanks!


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.


When I trying to install twinkle, I recieve such error:
I tried to fix twinkle a few weeks ago, and I did get it further, but I didn't fix it completely. I can try to find the WIP this evening if someone is interested.
I managed to fix it in the end. Details are in the commit message.