jiebi/CodeConvo huggingface dataset:
In the dotnet section of the nixpkgs manual, However, the behavior is actually the same if is unset or : all executables are installed. The behavior is expected if is a non-empty list. First, package a dotnet module like this: <details</summary</detailsThen, build the package, and look at the dir : As can be seen, some executables (actually, all of them) are installed despite that . If change to , the result is expected: According to the manual, the expected behavior when is that is empty or nonexist. In the definition of , the phase has something like this: Seems that an empty list is falsy here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can reproduce
The code is actually which means , then this results in the string and the alternative code path is executed. What I don't see is why would be either in this case...
After debugging it appears that this is being caused by these lines The if condition for does not succeed, as it is empty, so it goes onto the block. Now is iterating over each path given by and spitting out any executable seen in , then it gets wrapped by
It is expected that every executable is wrapped in the block (the behavior when is unset). Something should be modified so that it enters the block instead of the block when is an empty list. Oh yes, I guess I need a pair of glasses (maybe just copy and paste next time). If is unset or null in the shell script when it is an empty list in the nix, I guess the actual problem may be in the definition of ? An empty list becomes null somehow when did the substitution, it seems. I have not debugged it, though.
Errors with: This error has already been fixed in by (See also MultiMC/MultiMC5.) MultiMC successfully builds if you set the version to develop: Attempt to build MultiMC. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Would also be fixed by (Edit: only the CMake errors, include patches are probably still necessary)
Probably best to just patch the release. I'll see if I can do anything about this. I need to fix the desktop file anyway.
Patching doesn't work, and calling the commit directly results in this. Not sure what to do. If someone does fix this, please include in to fix the desktop file.
I managed to fix it by using the unstable version, but I'm not sure if that's the right approach. I can make a pull request with that if you'd like.
It should be fine, just note that it's a temporary workaround until MultiMC increments a release, since IIRC stable packages aren't generally supposed to be using non-stable repos.
in secret management was redone for bookstack. Now I can't place a mail password as secret. It's also appended with : Please run and paste the result.
Oh, sorry about that. I can't see any obvious culprit in the code and I really don't know where came from. Can you paste the service script as it's been rendered? Can you paste a configuration that reproduces this?
Oh, I suppose this could happen if the mail password file path is a superset of the app key file path. Is that the case?
I've submitted a fix for you to test: . I hope it solves this issue.
Describe the bug executing terminates with an error. This didn't happen with idris2 Version 0.3. To Reproduce See above and below. Expected behavior The REPL should successfully start and present its own prompt Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
Could you try setting ? In particular, they should be set here:
The library paths mismatch.
Hey, your seems to be empty. :O This is what my recent install () looks like:
huh, why does it seems empty, it clearly contains stuff?
Ah sorry, I misread the columns then.
Can you compile and run execs?
suggestion:
when I manually adjust the library paths to include the version, it works:
Run with
Will apply, though I am now concerned about the different behavior in NixOS, so maybe I am getting the libs from somewhere else DX
Rebooting a NixOS instance on ec2 does not resize the root volume even though Created one of the amazon ec2 instances: nixos-17.03.885.-x86_64-hvm-ebs Resize the ebs volume associated with the instance using the aws console. Reboot the instance. View to see that nothing has changed view Find this in the error logs: System: (Hummingbird) Nix version: nix-env (Nix) 1.11.11 Nixpkgs version: "17.03.885." Sandboxing enabled: build-use-sandbox = false
this commit makes my NVIDIA GeForce RTX 3090 no longer visible to ollama: needs to be revisited, or add optional flag to disable hardening (which i don't really need since I dont expose ollama over internet). when running through systemd: when running :
Can you check , and try adding these strings, prefixed with to ? For me on NixOS 24.05 they show and the module currently allows the following device types:
Just upgraded to the unstable module and package and things are still looking fine. The only nvidia related config I have is
, will try later when I get back home. Not sure if related but I'm on nvidia as the newer versions are broken in one way or another (wayland/performance regressions/pytorch issues).
You can also try nuking the DevicePolicy altogether if the suggestions above do not work: = { DeviceAllow = lib.mkForce [ ]; DevicePolicy = lib.mkForce "auto"; };
was the missing piece: +
--------+ |-----------------------------------------+----------------------+----------------------+ +-----------------------------------------+----------------------+----------------------+
thanks for your support!
Feel free to send a PR to add it to the module. Thanks for looking into this!
some additional findings, nvidia device group names are definitely driver version dependent, this is what I get on 555 ( is gone):
Electron is a security-critical component for several desktop applications and we shouldn't be keeping EOL versions around. Please remove all versions older than 18 if possible. The latest version is 21. via cc
There are at least 14 packages that require Electron < 18, should we drop them as well? Isn't it better to just mark Electron < 18 packages as insecure via ?
That is a start, ideally we could move those packages off older Electron versions, but I don't know how feasible that is.
After the recent update of nixos-23.05 from to (which included , updating Firefox from 119.0.1 to 120.0) Firefox started crashing, apparently when WebGL gets used. Steps to reproduce the behavior: 120.0 with a clean profile. a crash. Some crash reports: https://crash- https://crash- These crash reports point to , which shows a matching backtrace: The underlying problem might be somewhat different though, because the offending option is not present in any Hydra build logs ( is present though). system: host os: multi-user?: sandbox: version: nixpkgs:
You can disable WebGL temporarily while the bug is being fixed. about:config webgl.disabled set to true
also works without crashing even with WebGL enabled.
Hydra build log: This is the same root cause as described in (originally for Ubuntu Firefox Beta PPA for 18.04 LTS). This is caused by building in such a way that and (and ) embed and export their own version of the code from libstdc++ (in particular ) instead of using dynamic linking to call into the code that is exported by . It is unsafe to do that because of the flag that is used to compile these binaries, and starting with Firefox 120 that results in a WebGL crash. For the Ubuntu Firefox Beta PPA this was caused by compiling with but we do not understand why this situation occurs for the NixOS 23.05 build at the moment. But it does occur (see screenshot below). <img width="399" alt="Commands showing that indeed firefox, and all export std::locale::Sinitialize with this build" src=""If someone knows how to ensure that and (and ) do not embed and export code for , that should fix the crash (we should not see a for when using on these binaries, in fact we should not see it at all because this function is internal to the implementation).
Also apparently the problem is specific to the branch:
Comparing the “good” build log () with the “bad” one () shows the difference in clang versions (and the extra option for the build, which uses clang-15): And the difference is indeed in the compiler behavior.
Using the test file from the Mozilla bug report: With the new compiler from : With the old compiler from : Apparently the important difference here is that the compiler from passes the option to , and the directory contains , therefore the linker uses the definitions from the shared library as intended. However, the compiler from passes the option, which refers to a nonexistent directory ( actually exists, and there is the symlink, but these directories are not mentioned in the parameters), therefore the linker does not see and uses only from , so the resulting shared library contains copies of all libstdc++ functions, which breaks things when is also specified. So apparently the real problem is that in the branch uses wrong library paths for the GCC libraries.
I'm currently building with the following patch, thanks to trofi. This approach fails, as it overrwrites all previously accumulated flags. This was apparently fixed on master in
This will most likely be resolved through , but I'm still testing a solution that would be more localized to firefox and thus arrive quicker.
The workaround is part of the latest release-23.05 evaluation. You can follow its progress here:
Describe the bug /dev/fuse isn't user read/writable To Reproduce Expected behavior Additional context I've been testing with and : Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
After further testing, I found that reverting fixes the issue. I'm guessing that this new file needs to be installed somewhere. CCing maintainers of systemd:
There are even more tmpfiles configs that we're not using. I'll check what applies to us and prepare a PR.
It would be cool if there was a test for the permissions.
I have the same issue with /dev/fuse for can't mount remote sshfs as user only as root la /dev/fuse 10.6s crw------- 1 root root 10, 229 Sep 23 14:36 /dev/fuse ~sshfs user ~/sshfs/ fuse: failed to open /dev/fuse: Permission denied Any fix we can expect soon?
Seems permissions is associated with systemd /etc/static/systemd/system/kmod-static-nodes.service
apparently that broke permissions for me, which are needed for
Strangely, on my 19.09 system does have 666 permission, despite containing a line .
I think the permission is automatically set to 666 by udev rules when the fuse module is loaded.
In my system on 19.09pre channel I have this issue manifesting in kbfsmount failing with a permission error. crw------- 1 root root 10, 229 Sep 23 21:48 /dev/fuse
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]:
Steps to reproduce the behavior: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hydra can reproduce:
I tracked down the potential source of this failure, and am working on a fix. These builds take 30 minutes for me though, so it's slow going.
Please see for a fix. Testing appreciated.
Thanks for the quick patch. EDIT: My way of installing to profile didn't pull the fix, I'll see if I can figure out a way to do it properly using the pr review package
Builds and runs... seg faults as soon as I load a model, but that's an AMD driver thing (whole WM crashes)... Ship it :laughing:
I did see some segfaults, but was able to restart and get it to load on my 6700xt. “Glad” to know it’s known and common.
Nice! Thanks for this - excited to see it roll into unstable soon. Ollama seems to always have some issue - is there a "working group" that has some focus on this program and nix? Anyway, thanks again!
The problems with crashing aren't nix problems, they're crappy amd driver issues. It doesn't crash if you don't load models close to the max vram available... obviously it shouldn't crash if you do, but amd... so yeah
Steps to reproduce the behavior: cmus on current (). Full logs: I haven't updated in a while, so I'm not sure where this failure starts. Nothing has changed in the cmus package; it must be a change in dependencies. system: host os: multi-user?: sandbox: version: channels(root): channels(jamesw): nixpkgs:
cmus started failing somewhere between (good) and (bad). I don't have the hundreds of gigabytes of RAM that would allow me to do a bisection between those, so I'll leave that to someone else.
Manually going through it suggests as a possible culprit. I have no idea what that commit does, though, yet.
the issue is bump of ffmpeg to 6, i am about to push a fix
Steps to reproduce the behavior: nixpkgs electrum was recently updated 4.3.1 -4.3.2: previously built fine on nixpkgs 2022-09-28 () <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --<!-- attempting ti bisect, but on a slow machine, and it looks like there's miscellaneous failures over this duration so not sure it'll bisect cleanly: --
bisected to: good: bad: that's the staging-next merge though, so a lot of surface area. however, we appear to address a very similar build failure over in pkgs/development/python- by doing: i'm not sure how to test this same patch on electrum since it doesn't have any file.
oh just kidding, Electrum just places its in a different location. the patch below fixes the build when applied to master, and the application starts but i didn't test any functionality that i know touches protobuf. not sure how concerned i should be about overriding a pinned dep (i'm not a python dev):
Fix in
Possibly a regression after CC <!-- 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]:
Log The clue is in this log line Odd that we'd be copying something to a derivation ending in , right? Let's investigate further. is one of the CUDA redistributables, so I know it's built by the manifest builder. Looking it over, we can see the relevant portion of the : Well, that looks about right, but what is it actually rendered as when building? Uh oh. Yeah, that's right -- we're missing a newline character! Turns out using the multiline string literal doesn't mean we get a leading newline character (which makes sense given that we concatenate them everywhere and we're not drowning in empty lines). With just a small patch Our is what we would expect: And the resulting build contains our binaries! More generally, the problem likely caused the last, non-, output to disappear.
Will be
I suppose it wouldn't be unfair to say that this is an instance of the "we've stringified our data and failed to parse it again" issue?
I think that’s fair to say. As I view it, the actual build is always done by a bash script. We can either write it entirely in bash, or template it (like we do currently). Both come with tradeoffs. In my opinion, the boost we get in expressivity from lifting some parts of the build up into Nix expressions (so we can use attribute sets and functions in the library) outweigh the cost of making sure we’re producing well-formed bash. Although, that does fall apart sometimes (like here, where we were missing a new line). I’ve not tried to rewrite the install phase as a static bash script which leverages structured attributes, but I do wonder if it would have been as easy to debug? At least with the approach of using Nix as a templating language for bash we can use nix eval on the install phase to see the result. thoughts?
Yea we can also use to peek at the attributes that would go into the JSON, and then maybe there's less bash to read
Package name: libjson-rpc-cpp Latest released version: 1.3.0 <!-- Search your package here: --- Current version on the unstable channel: 1.3.0 Current version on the stable/release channel: 1.3.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 no 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]:
First release in three years. <!-- 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 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: <!-- The current version can be found easily with the same process as 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.6.4 desired version: 1.8.0 <!-- 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.
cc who might be able to help with building the extension from source
Describe the bug It seems you can't disable GDM's auto suspend behaviour. Disable has no effect. To Reproduce laptop will auto suspend after timeout Expected behavior Suppress auto suspend. Additional context Follow up from Notify maintainers Metadata
I'm on Wayland if that matters.
I believe it only touches the dconf profile in gdm, and sets these settings You probably still have those set in your actual session. See the OP of for more details.
Though I could be misremembering things
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Not sure if it will work yet, but I ran these commands to make my settings match the autosuspend = false settings:
After making these changes, it still suspended. Then I killed , and since it has restarted it has not auto suspended. I'm not sure if this is the simplest thing, but what worked for me was: set , rebuild NixOS Kill so it restarts
returns nothing for me on unstable. I have set to false and it still suspends. (I not 100% sure this is caused by gdm).
Well, it started auto-suspending for me again, even with the above settings.
I'm trying this now:
Seems to be working!
In my case it was xorg, not gdm at all. I disabled screensaver and autosuspend with:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Wow, it's 2023, and this still appears to be the solution To clarify I actually did the suggestion in here, which has an additional line
I vote to reopen this. The fix is easy to configure, but difficult to understand.
It seems like "don't suspend my system, i'm running this as a server" should just be a single config option
Describe the bug The unifi controller has dropped a present in my : Seeing as Unifi support has asked me about "temp", the "device tab", and my network topology, I'm not holding out on getting a good answer as to what it's doing. Short of that, I'd like to prevent it from having any access anywhere except a single temp, non-executable location managed by systemd.
I marked this as stale due to inactivity. &rarr;
When the service starts, the following message is printed to the logs: sshguard[]: sshg-fw-ipset: Could not initialize firewall Blocking does not actually work. Blocked hosts can still initialize ssh connections. Default sshguard config. system: host os: multi-user?: sandbox: version: channels(root): channels(XXXX): nixpkgs:
It seems like that is due to ipsets being created of different types than intended. I'm not sure where it's getting created with that though: # ipset -L Name: sshguard4 Type: hash:ip Revision: 4 Header: family inet hashsize 1024 maxelem Size in memory: 88 References: 1 Number of entries: 0 Members: Name: sshguard6 Type: hash:ip Revision: 4 Header: family inet6 hashsize 1024 maxelem Size in memory: 104 References: 2 Number of entries: 0 Members: Whereas the script intends to create types which is why it returns with an error. I do not see where in the sshguard is type of ipset getting created. I came across though.
Nixos build error when using a MQTT sensor, following . being the channel. The corresponding line seems to have been removed in : which is the commit for the update to . Maybe the code has changed and the python script no longer recognises sensors correctly ? system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The configuration you listed above does not yield an evaluation error. I have verified that by building it myself. You must have specified somewhere else.
I don't have any other mention of in my config, although I have also configured an external mqtt brocker with which might change the evaluation. I can confirm that when I remove the sensor config, the evaluation error goes away, which is why I didn't think I needed to include the brocker config. Those are the only mention of in my config I promise! Still it's strange that the line was removed from no ?
I've just noticed now that I have forgotten in my config... Here is the actual pieces of relevant config:
That's the default. No need to include it. After all, I was able to reproduce your error by building NixOS from the stable channel. My bad. It's caused by the following line: which will use the from the stable package. However, if I set I get which I still have to investigate.
I really have no idea what's going on. The way I test this is by having a file with the following content: and a checkout of the branch with the following diff at : When building the configuration I get What's strange is that there is no error when points to the branch with the diff applied. Maybe or have a clue.
I am happy you could reproduce this! Still, I don't see any line for in the (but I see it in the ), which I think it will lead to problems when it will be merged, no ? What I still find strange, is that the referred file in my original error is from ... Is this making any sense ?
Yes, this makes sense: The module is taking the list of from the stable channel and passing those used in your config to the package from the unstable channel, which obviously can't find the component since it's no longer in .
Ok, thank you for your explanations, I understand where the error comes from now !