Describe the bug Shell with and will fail to start with a following message: This is an issue because depends on so they would be always included to the shell started by nix-review. I noticed this issue while reviewing . I suspect this is caused by . To Reproduce Steps to reproduce the behavior: This does not reproduce on release-19.09 Expected behavior Shell will start, shell prompt will appear. Metadata Please run and paste the result. Maintainer information: cc
I'm getting "CLASSPATH: unbound variable" since updating master an hour ago from last Sunday, and reports "JAVA_HOME: unbound variable" started happening while working on eleven hours ago.


The IGV package freezes and crashed when a file dialog should open (open file, save as, etc.). Steps to reproduce the behavior: igv: igv "File" -"Load from File.." application crashes The file dialog should open and allow me to open a file. If I open igv through the terminal, then this error is shown: This error is the same as previously reported issues for other application, e.g. I'll shortly open a PR with the same fix. I'll rather do that in the PR with the fix. Please run and paste the result. NA


Steps to reproduce the behavior: for n/a <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --built from nixpkgs master () Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


The version claimed to be produced by the openmw derivation is , however once installed it is still version system: host os: multi-user?: sandbox: version: channels(avery): channels(root): nixpkgs:


Running shows a version that is different from the one in the Nix store file name. Run The output will look something like: Notice the store path says while the command show that the version is actually 0.19.12. The two versions match. I ran into this because I tried to use and got the error "has no attribute 'replace'": According to this part of the API was released at least in version 0.19.16, so it would confirm that the version I have installed is in fact 0.19.12. <!-- 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 only updated the version and not the hash.
Thanks, well spotted! when I merely update the hash I end up with this error:
hey, after having had just a quick look, I've opened I haven't tested though, could you help with testing and let me know if that works ?
ah, I've just had a compilation failure. This is because the maturin used currently is 1.3.0 and polars requires 1.3.2. the bump is also going to require a maturin bump. Are you interested in taking care of it ? Otherwise I should be able to make some time at some point.
Thanks for this! I might try it out in the next few days :)
alright, I've tried with maturin 1.3.2, but I still get a rust compilation failure. I've checked their MSRV and it's only 1.71. So I don't know what could be causing this compilation failure. if you have any ideas, feel free to re-use anything from that PR without any need for attribution. I'll be happy to help merge a solution.
might be worth setting the version back to in the meantime so the package will build on a cache miss.
so version has been set back to 0.19.12. I have finally had some luck in compiling the latest polars version in if anyone is interested to test the PR, feel free to post a comment. I'm running a nixpkgs-review to check what the update breaks


, CVSSv3=7.5 (nixos-21.05) CVSSv3=7.5 (nixos-21.05) CVSSv3=7.5 (nixos-21.05) NLnet Labs Routinator prior to 0.10.2 happily processes a chain of RRDP repositories of infinite length causing it to never finish a validation run. In RPKI, a CA can choose the RRDP repository it wishes to publish its data in. By continuously generating a new child CA that only consists of another CA using a different RRDP repository, a malicious CA can create a chain of CAs of de-facto infinite length. Routinator prior to version 0.10.2 did not contain a limit on the length of such a chain and will therefore continue to process this chain forever. As a result, the validation run will never finish, leading to Routinator continuing to serve the old data set or, if in the initial validation run directly after starting, never serve any data at all. In NLnet Labs Routinator prior to 0.10.2, a validation run can be delayed significantly by an RRDP repository by not answering but slowly drip-feeding bytes to keep the connection alive. This can be used to effectively stall validation. While Routinator has a configurable time-out value for RRDP connections, this time-out was only applied to individual read or write operations rather than the complete request. Thus, if an RRDP repository sends a little bit of data before that time-out expired, it can continuously extend the time it takes for the request to finish. Since validation will only continue once the update of an RRDP repository has concluded, this delay will cause validation to stall, leading to Routinator continuing to serve the old data set or, if in the initial validation run directly after starting, never serve any data at all. NLnet Labs Routinator versions 0.9.0 up to and including 0.10.1, support the gzip transfer encoding when querying RRDP repositories. This encoding can be used by an RRDP repository to cause an out-of-memory crash in these versions of Routinator. RRDP uses XML which allows arbitrary amounts of white space in the encoded data.


The gzip scheme compresses such white space extremely well, leading to very small compressed files that become huge when being decompressed for further processing, big enough that Routinator runs out of memory when parsing input data waiting for the next XML element. Scanned versions: nixos-21.05: . Cc


On aarch64-darwin, while neovide does build and install successfully and I can launch it from the terminal, there is no app bundle that can be found in finder to launch neovide from there or pin it to the dock to launch from. Once opened the global menu calls it .neovide-unwrapped and the icon in the dock is a blank white page as a generic icon. I can only assume that once is fixed, that this will also be applicable to x86_64-darwin Steps to reproduce the behavior: neovide as either a system app in nix-darwin or a user app in home-manager on aarch64-darwin An app bundle name that will be linked into or depending on and usage I'd like to point out that the global menu title is .neovide-unwrapped to for sure indicate that this is the nix neovide and not the homebrew neovide ! ! <!-- 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]:
Following PR MacOS app information a few days ago: We can install the files with next release of neovide.


, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
09 is still vulnerable
NixOS 20.09 is EOL, so this issue isn't actionable anymore.


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


Describe the bug When I did we assumed that variables like and would be replaced with or . This is not true and in the pam configuration we have variables. cc


Unable to build libxml2 Repro: nix-env -i libxml2 make[4]: Entering directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' CC CC libxml2- CC libxml.c:1649:43: warning: passing 'unsigned char ' to parameter of type 'const char ' converts between pointers to integer types with different sign [-Wpointer-sign] message = libxmlcharPtrConstWrap(ptr); ^~~ ./libxmlwrap.h:240:48: note: passing argument to parameter 'str' here PyObject libxmlcharPtrConstWrap(const char str); ^ 1 warning generated.


CCLD ld: library not found for -lintl clang-7: error: linker command failed with exit code 1 (use -v to see invocation) make[4]: [Makefile:600: ] Error 1 make[4]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make[3]: [Makefile:694: all-recursive] Error 1 make[3]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make[2]: [Makefile:528: all] Error 2 make[2]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make[1]: [Makefile:1479: all-recursive] Error 1 make[1]: Leaving directory '/private/var/folders/7g/1ptqqd597r76dqzk7hjy0bgc0000gn/T/nix-build-libxml2-' make: [Makefile:893: all] Error 2 builder for '/nix/store/xcqdl8cfjjbjvh7g9ka0ip3r4awy80a8-libxml2-' failed with exit code 2 error: build of '/nix/store/xcqdl8cfjjbjvh7g9ka0ip3r4awy80a8-libxml2-' failed Metadata* system: host os: multi-user?: sandbox: version: channels(swarnpriya): nixpkgs:
Disclaimer: I barely know what I'm doing. I tried adding as a build input to libxml2. That got this error:
I've been getting this as well, since . Any clue? I think this sort of thing has happened before, but I don't recall the details.
I thought somebody else already fixed this after some discussion no irc. My proposal was essentially the patch above but guarded for python2 only.


Steps to reproduce the behavior: Commit seems likely to have broken the build for bitsandbytes. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I suspect the above output is related to that commit modifies or creates the module referenced above. I'm rebuilding setting the to and to to see if having dummy definitions solves the problem. Unfortunately it's slow going as it requires a full pytorch rebuild to see if it repaired bitsandbytes.
the trivial fix proposed above appears to resolve the build. Not sure if this would have ramifications elsewhere in the tree. Happy to PR the change if others want to help kick the tires
Oh!!! was mean to be a not ... how on earth did this even pass the tests (i.e. I only meant to abuse python's imperative-ness to override and keep all other symbols intact...)
a PR would be very welcome
looks like your original idea should also work, and be less broken in mysterious ways, I can do a quick PR after I make sure it works on my end.


Gotenberg crashes immediately on startup Enter the following into your nix config: It not crashing but starting up normally ! Gotenberg was to be used in conjunction with paperless-ngx. is the entire file Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are there any more logs from the Gotenberg service? Or is the coredump all that's available?
Sadly that is all. The service log literally doesn't say anything. There you only see that the service started and immediately exited. This log i got by typing
Sorry for the slow response, but I looked at this and figured out the issue. Could you test and see if it fixes your issue?


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


I saw the following during a rebuild: Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/ttf" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/ttf" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/opentype" is an invalid MIME type ("font" is an unregistered media type) Error in file "/nix/store/vwd5hb2n6m7nwqijlz0rsmn5x6fpmlhw-system-": "font/collection" is an invalid MIME type ("font" is an unregistered media type) Unknown system: host os: multi-user?: sandbox: version: nixpkgs:
I think we just need to update , c.f.
Ah, it seems that upstream has not released a version with the fixed commit in. The last tagged release was , they haven't tagged anything with the fix commit in. We could build from their git head, I guess, although I'm reluctant to do so. Perhaps complain ?
If the commit applies as a patch that would also be fine.
I'm still having this. had it for build and build (separately). build


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


Steps to reproduce the behavior: pyload-ng <!-- 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]:
Thank you for notifying me, the failure is caused by the lib not yet working on python 3.12. Apparently the git upstream of pyload replaced it with which I'm packaging in , so once that's done I'll get around to updating pyload (will probably have to switch to the git version since they rarely upload new releases to pypi). For now you can override the python version as a workaround:
The override works great. Thanks!


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


All expressions in nixpkgs are supposed to be MIT licensed, but is licensed under GPL-3.0. as an externally developed project under different licensing terms that we use for nixpkgs. It was merged into nixpgks in without the license being changed to MIT or a compatible license. Every package using is using improperly licensed expressions, which at the time of writing looks to be a bit more than 25 packages. I have two proposed solutions, neither of which are particularly appealing: -license under MIT This would require assembling relicensing signatures from all existing yarn2nix authors which include both contributors when it was in nix-community & in nixpkgs. It's gonna take some time and keep us in license non-compliance in the mean time. , migrate packages to something else The newly looks like a good contender as pointed out by in chat. CCing authors and other relevant parties Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Just to repeat what I said on Matrix, if we can’t figure out something better in a few days I will open a relicensing issue and start the work of pinging all the contributors. Reimplementing it sounds nice, but I suspect it would take quite a while given the speed at which Nixpkgs language ecosystems tend to move.
yarn2nix can be easily misused and trigger IFD. I think too that in the long run we should replace it. Maybe yarnBuildHook/yarnConfigHook from are already enough and the package can easily be migrated?
(Nixpkgs potentially actually being GPLv3 is very much a bug IMO.) Migration is all well and good, but we probably ought to try to relicense anyway: we can’t change old revisions of Nixpkgs and it’s not good for multiple years of Nixpkgs history to be under unclear licensing conditions.
I guess re-licensing is the better way for now? We can ping all the contributors, from a glance I read most of the names before.
Yes, I think we should probably at least try. I will open a new GitHub issue for it today so that we can discuss here without it getting bogged down in rote responses.
Okay, here we go I guess:
Oof, thank you for trying to clean up that mess.


I just got the notification from the tracking issue and I feel that a big portion of any blame should go towards my direction because of the introduction in , rather than While I (try to) put a lot more thought into licenses today, it didn't cross my mind back then that vendoring with the included license could have such implications.
No worries – thanks for trying to improve the Node packaging situation in Nixpkgs and for your quick reply to the ping! This is an institutional failure IMO, and I think that it would have been caught before merge these days.
seems still active. It might be worth posting the same as on Discourse if you want people's replies to be public (unlike with email).


Steps to reproduce the behavior: -env -iA (full output here: ) 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.
The error is not in pgcli but in psycopg which tries to import a .so which does not work under darwin.


The project seems slow with releasing the latest changes, which (among other things) includes Package name: tiramisu Latest released version: 2.0., I suggest using the latest commit instead since there is no newer release yet <!-- Search your package here: --- Current version on the unstable channel: 2.0. Current version on the stable/release channel: 2.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.


Describe the bug The example given for does not seem work as expected. To Reproduce Steps to reproduce the behavior: the following to nixos-rebuild switch Expected behavior Creation of a proper ceph client configuration. Additional context I am trying to build a NixOS configuration with a minimal ceph client configuration. Metadata Maintainer information:


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


Hardening gives old Clang flags that it cannot handle and fails. A same problem, I imagine, would arise with old GCC versions. A possible solution is to list somewhere what hardening methods are supported and use the list when deciding what hardening to apply. For example: a file : an error. Nixpkgs version: (run ) Sandboxing enabled: (run ) yes


Describe The package rtl8821ce can't be compiled due to errors.
The package is the upstream GitHub repository it tracks which is the cause of this breakage. Bumping it to master should suffice in resolving this. Specifically, commit is the one that fixes the failure I too observed in rtl8821ce today while setting up NixOS.
fixes this for me and WiFi works perfectly.


Trying to update a system to the latest "release" () results in the following error: I don't know how to easily reproduce this. At least for me, it seems to happen because the needs to adjusted. So: Try to update a system that (at least) uses ZFS I guess ... No build failure. N/A It looks like this was caused by . I'm not sure if the ZFS module is the only place that needs to be adjusted after this PR has landed. (authored the PR mentioned above) (approved the PR mentioned above) (ZFS maintainers) Please run and paste the result.
For now, I'm not sure, I can reproduce on 23.11pre504982.. It seems like the fix is obvious though.
While I understand how to adjust the two lines in , I don't know how to deal with the other occurrences of in that file.
Usually you can replace "PATH lookup handle where this binary actually is.
I have a potentially fix in
Someone should prove that before the fix, this was broken with a NixOS test ideally and with this fix, this is unbroken.
I suspect it's related to and that that's not covered by any of the existing nixos tests.
And that in turn can't trivially be tested end-to-end because nixos-generate-config doesn't actually support non-legacy zfs mounts... I've written a test and a little prose about the issue:
Maybe we should consider adding them. Using new mounts is rather convenient when the disk needs to be mounted in a live iso.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Ran into the same exact issue over here. Also running on ZFS root. (The discourse link above is mine.) EDIT: Fixed by updating to master. I think I'll be converting to flakes soon, thanks to this
Fix reverted because it broke basically the entire nixos test suite:
I get this with NixOS 23.05.
are you sure it's exactly that? The util-linux split isn't even on 23.05 so that would be very weird.
Yes
That sounds like you're somehow using unstable util-linux for the stable initramfs generation, and it's not surprising that that would break.


You can try confirming this by temporarily setting both nixpkgs to point to the same (doesn't even matter if it's unstable or stable).
I have unstable for Alacrity which is an application, I don't see how that would affect initramfs generation.
And I don't see how you'd get a split util-linux from 23.05, since wasn't backported there.
Indeed: And in fact: Which is a different util-linux version number than we see in your error message. Finally, your nix flake metadata says your using , and: So something fishy is going on here. You've got an overlay or override or something that's pulling in a different util-linux from unstable. Either that or there's some other build that's occurring as an unexpected transitive dependency that's building a nixos system using an unstable nixpkgs that doesn't contain the fix. Either way, I feel fairly confident in saying this is some obscure and subtle user error.


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


Our current legacy nvidia driver of the 340 branch does not work with kernel version 4.19.2: NixOS is currently on the 340.104 version, but upstream is on 340.107: I hope that updating to 340.107 resolves the issue, but I don't understand how to update the different checksums for the nvidia driver. /nix/store/kic17fw8wil74k04kzh3dha43izrr9j3-bash-interactive-4.4-p23-dev copying path '/nix/store/kic17fw8wil74k04kzh3dha43izrr9j3-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The hashes are located at and can be generated like so: Please try:
Thanks alot for giving me a hand and teaching me how to get those four hashes! :+1: Updating to 340.107 indeed resolves this issue. PR:


Hi. Some Emacs packages which were ok at 16.09 got broken with 17.03 Adding leads to error If I activate , Emacs shows the error . It doesn't matter whether it was installed from or . One from loads but produces a warning System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run )
With regard to the sha issue with ---I think this is just an inherent conflict between melpa being willing to get code off of , and nix's desire for stable identifiers---if you look at the sha on , it matches what is expected, but it only dates back to 2017-03-02. should we update the sha in the expression for the release?
With regard to ---whatever it's baroque initialization code is doing, it is apparently not smart enough to simply , instead electing to get itself into some infinite-seeming loop. I would suggest reporting a bug upstream. Doing that manually allowed it to start, at which point I discovered it was apparently written by someone who doesn't actually like emacs---I barely escaped. :) Good luck!
I have the same problem with a fresh NixOS 17.03. Script to reproduce this problem: Will produce the following output:
Thank you much for fixing zerodark-theme! ergoemacs-mode fixed in


Project description Ciao is a programming language that builds up from a logic-based simple kernel, and is designed to be extensible and modular. Its supports: constraint logic programming (and, in particular, Prolog), different levels of modularity (from small to large scale): modules as (analysis-friendly) compilation units bundles as collections of modules, packages as modules implementing language extensions (syntactic definitions, compilation options, compiler plugins), assertions (as a homogeneous framework that allows static and dynamic verification to work cooperatively in a unified way), multiparadigm constructs (meta-programming, higher-order, mutables, concurrency, functions, etc.) and interfacing with foreign code. Metadata homepage URL: https://ciao- source URL: license: lgpl2 platforms: unix, linux, darwin


Describe the bug The description of is: Path to the unix socket file on which to accept FastCGI requests. This option is read-only and managed by NixOS. So i can't set it. But how can i figure out how the socket path is now? Please add an example to the description! To Reproduce Steps to reproduce the behavior: option desciption Expected behavior Useful description. Metadata same in 19.09 and 20.03 Maintainer information:
The point of the option is that you don't need to find out, just reference it. That being said I agree with your issue and it would be helpful to set an example
The point of the option is that you don't need to find out, just reference it. Sure, that works in but i have that path explicitely in my webserver config which is next to the content, e.g. . For reference: The path is actually as i set it before: So i can just remove the option from my .


When adding as a plugin I get: . completes without issue. I have plenty of other vim plugins in the exact same manner without issue.


Building the manpages for this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems. You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: (please share the relevant fragment of the diffoscope output here, and any additional analysis you may have done)


Describe the bug A clear and concise description of what the bug is. I am using nixops to manage a number of machines, some of which use nixpkgs-unstable. When deploying a machine with nixpkgs-unstable, I started getting errors stating . These are likely linked to a change in the last week or so, as I've been able to deploy the same machine perfectly fine last week. When run with , I get: After getting this error the first time, I initialHashedPassword to all 2 of my users, as well as root, as follows: This fails with the same error. Deploying with nixpkgs 20.03 works fine. The error seems to originate from , specifically: I also tried adding , which naturally fails as that attribute doesn't exist. It also fails with the same trace when using instead of To Reproduce Steps to reproduce the behavior: to deploy a machine (maybe nixops is required?) with the latest nixpkgs-unstable Expected behavior The machine should deploy normally, even without , as it used to last week Screenshots N/A Additional context I suspect it might be linked to Notify maintainers - Tagging you as your PR was the last one to touch this area Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(raghav): nixpkgs: I'm using nixops release-1.7 Maintainer information:
Yeah, this really smells like .
Argh, I made a stupid typo. I'll fix this ASAP.


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


default value causes previews to fail. the usual homeserver config Do not configure (so that the default value is used) Post URL into a preview enabled room Find similar error in synapse log: The option defaults to . Were those values intended as default for the option? Excerpt from a working configuration: /cc (as you discussed the security implications in )
Seems like a good bet.
thanks for fixing this, I was just wondering about this earlier today:


I'm getting an error /nix/store/jx2hdq8n3fdj0bm58qxgy0psyyl0vd05-nuget-to-nix/bin/nuget-to-nix: line 56: baseaddresses[$usedsource]: unbound variable when trying to generate a lockfile for . Steps to reproduce the behavior: this simple file: to generate the script the error Be able to generate the lockfile. If applicable, add screenshots to help explain your problem. Add any other context about the problem here. I guess was the one to introduce the variable there.
could you give a try?
The problem seems to be that there's a repo in the sdk at , containing only . This is somehow referenced implicitly. I'm not sure if we should do anything more to handle this situation, but the message fix should do for now.


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


Upon launching,  white screens without any visible errors. or the app white screen It works without white screening Since runs fine when using its pre-built AppImage, I don't suspect that there is any issue with my hardware, drivers, or software. After testing, I have found out that the issue exists on specifically. It works fine on KDE. (Note: I haven't tried on similar environments like Sway) Running produces the following output upon exiting : Hello,
I am thinking of adding a package so that any user facing this or similar issues can use pre-built binaries as a instant solution than waiting for existing nix expressions to be fixed. Please guide me if you guys think this should/can be done. (The NixOS manual doesn't provide much help with wrappers around AppImages)
Could you please run in a terminal (in the environment where the issue occurs) and paste the output in a comment, in a . I also have a few questions, you get those same errors when you run from the terminal? this X11 KDE, or Wayland KDE? is your GPU, and which drivers are you using? I don't think we should do this. If a user wants to run pre-built binaries from upstream, there are straightforward ways to do so. Since Heroic ships an AppImage, you can use .
I've already tried running heroic from a terminal and weirdly, there's absolutely no error that shows up. Which makes me think it's a purely front-end error given heroic uses electron. , I do. KDE . My driver setup is contained in Yeah, that makes sense. But how do I make sure it's always installed on my system? Do I have to run every single time I need to launch?
Update: I have tested this in Sway as well and the app does white screen with no errors in the terminal.
Try running Heroic from the branch I just pushed (command below) to see if it resolves the issue. I've changed the Electron version the package uses to match that of the upstream package, as there seems to be a regression in the latest version of Electron.
Just tested this. I don't get the white screen anymore!!
This happens for me now, trying the nix shell now.
That fixed it, thanks!


Package name: zoom-us Latest released version: 5.15.2.4260 <!-- Search your package here: --- Current version on the unstable channel: 5.15.0.4063 Current version on the stable/release channel: 5.14.7.2928 <!-- 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.


When used with latest Nix the "new" hash is extracted incorrectly, or thereabouts. This seems to be due to Nix changing the message used to be more friendly to humans: Use an update script invoking common-updater-scripts. Sorry, LMK if repro is needed. Please run and paste the results. I don't expect this to be helpful but happy to provide anyway! system: host os: multi-user?: sandbox: version: channels(will): channels(root): nixpkgs:
It is increasingly messy, perhaps we can drop the old regexes, most people probably set instead of changing nix in overlays so this would not be affected.
What about adding a flag to nix, which turns on machine readable error messages with a guaranty that those messages will not change in a backward incompatible way? Would need someone to add that. But wouldn't that be better to parse error messages intended for human readers with shell tools?
Alternatively, if the build fails, I think we could do something like:
I'm not sure I follow, but FWIW I ran into this and I set and don't set it via overlay. Looks like the new behavior is in 2.2, the current default for : (err formatting might not work for email responses, maybe? sorry :)) I think it's reasonable to drop support for nix older than what's in the tree-- especially since you'd have to overlay to replace it and as you say would likely do via anyway. Oh... that's probably what you meant! :D
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Any updates on this?
I marked this as stale due to inactivity. →
Should have been fixed by
Thanks!


Describe the bug On a cold boot, exits uncleanly, leaving a black screen. This issue seems to have appeared on 20.03 (stable) up to the (at the time of this report) latest channel. Running from a different TTY will immediately load Plasma with the expected automatic login. To Reproduce Steps to reproduce the behavior: as an import at the top of the system configuration and set Expected behavior Automatic login to Plasma after the Plymouth screen. Screenshots No screenshots, but here's an excerpt of the output of : Additional context Using the same configuration this issue appears on only 2 of my 3 machines. The affected ones are using Intel integrated graphics with SSDs, while the other one has an older AMD GPU and HDD. I'm unsure if this could be an issue relating to drivers (with autologin off, SDDM and X work OOTB) or the significant difference in boot times. Notify maintainers Metadata Maintainer information:
I can reproduce this on a machine with AMD graphics; the issue seems to be a race condition with individual user login not being permitted before SDDM starts. Normally you don't notice because it's done by the time you finish typing in your password, but with autologin enabled it doesn't have to wait for the human. I have had luck with this configuration: Which may be overkill, but does appear to work.
That doesn't sound like overkill to me. As a user, I definitely want the network and user sessions available before I log in! :sweat_smile:
Well yes :P But I mean, it's possible that it only needs one of or , not both, or that, say, implies so there's no need to explicitly list the latter.
I doubt this part: and are independent, and we need the display manager to wait until the other services are started, so we probably do need both. I'm not sure about the second part, I need to investigate.
I marked this as stale due to inactivity. →
Shouldn't be marked as stale, there are still . Would it be wise to start a PR for the tweaks suggested by They seem to work on hardware and configurations affected by this.
I agree, this is not stale. I think the suggestion above is the appropriate solution.
Thanks a lot, the annoying workaround is no longer needed and time to desktop is fast again!


Steps to reproduce the behavior: vimPlugin.deoplete-go Yet another python 3.12 distutils breakage <!-- 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: vulkan-validation-layers 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.
The dependency causing this is vulkan-utility-libraries: 1.3.269 -1.3.270 This version bump causes vulkan-validation-layers to fail. Its only dependency is and that is fine. So problem is
The latest SDK version is 1.3.268. vulkan-utility-libraries should be rolled back to that version; we should not be packaging non-SDK versions of Vulkan SDK components, and especially not piecemeal.
indeed reverting it to fixed the build and runtime


roc-toolkit fails to build on aarch64-linux, with the following error: roc-toolkit should build successfully. N/A N/A Please run and paste the result.
libunwind/libunwind looks relevant
Does upstream support this target?
Both libunwind and roc-toolkit seem to support aarch64, yes.


Both and are failing on master, which prevents nixos-unstable from advancing. Hydra log: Bisected to: Introduced in
Revert for now in order to get the zlib update to ? (also needs merging and maybe fixing additional stuff)


Describe the bug When using mosh/tmux is first read by the login shell that spawns mosh-server, which sets . The actual user shell spawned by mosh will therefor ignore this file and not set its fpath. For that reason all system provided completion functions are ignored.
This bug was introduced by in who changed this variable to . What was the reasoning for not changing the environment of interactive non-login shells?
Um, this was six years ago, but I will attempt to answer the question. :sweat_smile: Consider this scenario: log in and the shell environment is initialized. make some local changes to the environment, and export them. open a sub-shell and the shell environment is re-initialized. changes made in the parent shell environment are not present in the sub-shell, as one would expect. Basically, the zsh initialization process would clobber any environment that you tried to propagate from a parent shell into a child sub-shell.
Currently zshenv by default only set fpath and HELPDIR without exporting them. A parent shell would also not set those variables usually as they are shell local. It also sources a file called set-environment but this is protected by an environment variable called . Hence any modification done by the parent shell should persist as long as NIXOSSETENVIRONMENTDONE is not unset. This behavior deviates from what we do in bashrc and breaks common setups such as tmux/mosh or screen. Hence I would revert it.
I don't think, at that time, this worked as you describe, but it was six years ago, and I haven't used zsh in years anyway, so my memory is not entirely trustworthy. If reverting my commit fixes mosh and tmux, and doesn't obviously break anything else, then go for it!


Steps to reproduce the behavior: -rebuild with Just broke a few days ago. Right now I'm trying out Nyx's Cachyos Kernel, but I tried to change to pkgs.linuxPackages_latest. I have not tried to build it on vanilla kernel, as any rebuild fails right now due to this error. Something similar also happened with my framework laptop, but that seems to be resolved <!-- 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. Yes, its cachyos kernel, I to my config though and the issue persists. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably needs a update, I'll try looking at this when I get back.
Indeed there was a patch two weeks ago. Currently not near my desktop machine though.