jiebi/CodeConvo huggingface dataset:
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.
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 .
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.
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. &rarr;
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. &rarr;
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: 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
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.