jiebi/CodeConvo huggingface dataset:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
singularity cannot use nvidia gpu because it does not access 'nvidia-container-cli' Steps to reproduce the behavior: return result of ! This is because the path is not listed in , as also in a. It is caused by neither the option nor . I tried to handle it with override, but since it was called in , I think it is impossible to handle. Also, I created a conf file in as shown in the singularity docs, but it was not read. <!-- 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.
Thank you for reporting and sorry for the trouble. I'll look at the SingularityCE documentation again. (Those configuration options has been deprecated by Apptainer.) Also, I created a conf file in /usr/local/etc/singularity/ as shown in the singularity docs, but it was not read.  shold be what you are looking for. The overriden package can be assigned to . (If you would like to bypass all the overriding done by the module and directly specify the package to install for some special reason, you can assign it to .)
Thanks for the reply. I followed your advice and tried the override and was able to use the GPU. Here is the code This is simply adding a process to append the nvidia-docker path to the I mentioned earlier that when conf was entered in , it was not reflected, and the same is true for '/etc/singularity'. I referred to .
At least we have confirmed that in works and the path is replaced by , but the product does not seem to be recognizable.
Does setting the to make ldconfig search in help? This is modified from the configuration proposed by (). There's also (probably) related to this topic.
Adding the path of to works well. This once removed from consideration. Next we have a patched version of ldconfig. This does not append the path of to the config. The result was an error that could not be found, and it could not be started.
Oh, I already forgot about this issue. Absolutely coincidentally, but maybe efforts such as might open up a way to implement this hack more reliably.
Meanwhile, in my config I'm still abusing You probably already have guessed, but singularity in nixpkgs is configured to read this config from the package-specific directory, rather than from the global . You could in principle override this behaviour, but there maybe isn't much value in supporting that
I tried to enable the use of external sysconfdir (), but have encountered issue trying to specify a directory under with the NixOS module ().
Have you tried to apply both at the same time?
The SingularityCE Admin Guide says If the value of nvidia-container-cli path is empty, SingularityCE will look for the binary on $PATH at runtime. It should work as long as is found in the run-time , even when is not set. As nvidia-container-cli is alredy included in the PATH-prefixing wrapper, we shouldn't have to set the .
Update: I found a bug in the prefixed PATH of the wrapper introduced in . The prefixing should be specified as (in Bash) I forgot to add , causing the trailing to be missing.
The statement in the SingularityCE Admin Guide turns out to be wrong / irrelevant. The source code clearly states that nvidia-container-cli will only be read from the configuration.
(we need to patch nvidia-container-cli, for many reasons )
Eh, actually, closed semi-automatically. Apptainer with is fixed (on NixOS), but not with . The fix doesn't concern singularity-ce either, unfortunately. Shouldn't be hard to make this work with singularity too, but I'm out of bandwidth
Hi folks, I've been trying to get apptainer to run this (which I've done previously successfully with a slight ldconfig hack -- that doesn't work anymore -- on NixOS 22.11), that will make use of the machine's Tesla V100 to do some simulation stuff. The machine is running NixOS 23.11. Using the workaround from 9th of May post further up, I was able to get past the ldconfig issue, but now I'm getting an error saying the driver and CUDA are not in sync.
Before I start posting any details (I don't want to re-open this issue, but I'm also not sure if I'm just doing something wrong) I was wondering if the current implementation of singularity/apptainer on NixOS is expected to work, and I'm just being an idiot, or if there are known breaking issues? I've seen the other issues about singularity/apptainer here, but I'm not knowledgeable enough to make a judgement call if they are responsible for my problem or not. Thanks very much in advance!
(If I understood the message correctly) That usually means you need a reboot, and you should experience the same issue outside the container
No, the reboot didn't help either. For some reason, though, after upgrading to 24.05, everything "just works[tm]" again. So, whatever the issue was, thanks for fixing it (probably)! :)
Thanks to Nixpkgs 24.05 includes GPU-related changes/fixes to the package and the module.
Well more like thanks to ShamrockLee
The derivation is missing the directory to work properly. Steps to reproduce the behavior: A clear and concise description of what you expected to happen. is output without error. This can be fixed by creating the directory manually (). I guess this could be to the derivation. <!-- 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.
NixOS module provides those top-level directories. discussed with one of the main Apptainer developer in . He think it should be easy to specify a directory that will always exist at build time. Regalding this, I'm considering the possibility to put those dilectories under the derivation store path. Not sure if there would be potential problem using a store path as a mount point, but it seems to work without problem.
Could you help me take a look at ?
If you have time, please help me test the PR . It should fundamentally solve this issue. If applied, you no longer need the NixOS module or just to run images. It specifies the LOCALSTATEDIR as , making both Apptainer and Sylabs SingularityCE works without . (The image running still depends on and to run images, which might be the final obstacle to build images as a package without invoking a virtual machine. Other than that, it should not be an issue for most users, as are available on most of the UNIX/UNIX-like systems.)
I removed (the temporary fix for this issue) and ran the following and it seems to work fine: Thank you for this fix!
Glad to hear that! Would you mind ? I've heard that committers tend to merge PRs getting two approvals.
Done!
Mesa 21.3.2 present in is causing , and they point to , not yet fixed as of now. Reverting to nixos-unstable to Mesa 21.2.6 updates fixes the issue. Steps to reproduce the behavior: sure you're using Intel GPU nixos channel to No flickering should happen on the application screen. Mesa bug report has a video demonstrating the issue. If applicable, add screenshots to help explain your problem. cc: Please run and paste the result.
According to the bug report this seems to affect at least Blender as well. Anyway, we can leave this issue open for a while (in case it helps users to figure this out) but I don't think there's anything actionable for Nixpkgs (it's an upstream bug and we simply have to wait until a fix is released via a new version). It looks like the patch from should be submitted formally via a PR so that it might get included in Mesa 21.3.4.
This is also happening on qutebrowser for me, but only on the wayland backend. I have a temporary fix to just launch with , but this obviously disables the hardware. Works fine though so far for just browsing and work stuff, at least until a proper fix is merged.
It's unlikely that the patch will be applied for 21.3.4 (as no one filed a MR for it so far), should we apply it downstream?
I'm seeing this in qutebrowser as well (non-wayland)
I'd prefer to avoid applying a patch that hasn't been reviewed upstream.
+1 for what said. Luckily a developer from Intel started looking into this so let's see how things will develop: Ideally a patch will be ready for 21.3.4 but the release might happen in two days (unless it gets delayed) so it'll indeed be close (but we'll of course re-evaluate our options once the release is out).
Unfortunately it was indeed too close for the patch to land in Mesa 21.3.4. However, now there's at least an alternative patch from Paulo Zanoni (the Intel developer) and Giuseppe Ghibò (author of the other patch) and others confirmed that it's working: I've included that patch in Does someone have time to test it () and report if it indeed fixes the issues?
Thanks a lot for putting together a fix! I'm happy to test. Could you confirm I understood the instructions correctly? 1) integrate the code from the above PR into my nixpkgs tree. 2) put the following into my nixos config: 3) replace with the path to my nixpkgs tree. 4) run Did I get that right?
It's the easiest if you use a separate/dedicated Nixpkgs tree for Mesa ( in the example). That way you don't have to rebuild a lot of other packages (which would most likely still take way too long). You can also cherry-pick the commit to (I'd recommend doing that) which saves additional rebuilds (I only tested it that way so no idea how many many builds are currently cached for staging-next). The rest looks fine. And thanks in advance :)
It works like a charm. Thanks
Seems like this wasn't closed automatically once landed in master. Should be fixed now. And upstream merged the required patches in the meantime (s. note in ). And thanks for testing the fix and :)
Describe the bug If I change and enable when the cert/key in question already exists the group access will not be granted after rebuilding and restarting the . This is because a condition in the post start script does so only when the key is newer than the existing one. To Reproduce Steps to reproduce the behavior: without group/allowKeysForGroup and start the service to reques the certificate group and allowKeysForGroup again and restart the service, the ownership/ode will not be updated Expected behavior The group and chmod setting should be set on existing certificates as well as new ones. Metadata Please run and paste the result. Maintainer information:
Additionally, shouldn't chmod 0640 suffice on the files?
cc as potentially interested individuals
Package name: ollama Latest released version: 0.1.20 <!-- Search your package here: --- Current version on the unstable channel: 0.1.17 Current version on the stable/release channel: 0.1.7 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
20 was released.[^1] :tada: Had a quick look into the source changes. Seems that patching is required because of the integration of ROCm. [^1]:
I modified the title :-)
21 is going to be released very soon.
I opened
update: 0.1.22 is the latest version.
Seems update can be problematic. I've tried manually download and executing new ollama and encountered a lot of issues connected with ROCM libraries. After adding I've got it to state where it crushes: But before adding it seems also miss new version of because it was asking for but current unstable version have CPU works fine without mentioned ROCM packages.
This appears to have been resolved by . Reopen if it's not.
I'm experiencing the issue for a long time now, and it was really hard to spot and debug this issue. I'm talking about this line: It's kind of hard to give instructions how to reproduce the issue. In my case, whenever the dash script runs, every folder I already have configured, fails to update. The whole configuration thus fails to be uploaded to the server. I can inspect the and the by editing that dash script, and I can see that I get folders twice in the json arrays. Hence I'm not surprised I see the following error in syncthing's web interface: ! I expect the merge script to not a JSON array with no duplicate folders IDs. Transition most of the logic from jq to bash, for easier maintenance, and use and API, and use when . I'm working on a solution at the moment but I'd like to here your comments first. cc who wrote the original dash script, other people have touched that line ever since, was the latest.
To make sure that we are on the same page: Kernel: System: Nix version: Nixpkgs version: broke legacy packages (only tested with the -set). Multiple options to solve this: revert the commit (an update will eventually have to be done) make sure no-one depends on sqlalchemy legacy versions (this would be the best choice, but can require a big amount of work) re-introduce an outdated version only used by legacy version (I’ll prepare a PR shortly that follows this path) cc
To be complete, the build problem is a test failure: I also checked, we cannot downgrade sqlite only for few pythonPackages, the entire python (and package set) have to be changed. Any preferred way to go?
(We should check if we still need this version, have it removed locally for virtmanager, virtinst as it isn't used, but haven't had the time to push that)
Yes, this is the preferred way to go. I began that but did not finish it yet, and it impacts some important parts (it causes xen to fail) I would prefer not to break because of unsufficient testing from me. This is in progress but could require some time to complete.
FYI xen already fails on
FYI: I switched away from sqlalchemy7 in yesterday.
Apart from virtinst, acd_cli, beaker, coilmq, and geeknote are the only revdeps of sqlalchemy7, as far as I can tell.
I openned to do some cleanup on sqlalchemy7. There still is that explicitly require . The same work will have to be done for and .
This should have remained open.
Using an older version of sqlite requires overriding the derivations of the interpreters.
See
First failing build (4.9.76, but not always): Latest (4.9.77): Looking through the changes for any obvious culprits...
bisected to (as the first "bad commit"). cc
Reverting the commit on master fixes the build, but need to replace with to at least fix evaluation on cross. Since doesn't seem to build on cross (at least not on any architectures I've tried) I can't tell if this "works", but would be good to fix this on non-cross regardless.
See corresponding PR, this has been handled. Thanks!
<!-- 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: 25.0.1 desired version: 25.0.2 <!-- 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.
<!-- 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.7.3 desired version: 2.0.2 <!-- 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.
waiting for 0.50.0 release of
I fixed echidna.
Lovely. Thanks you so much for you effort.
The mpccli package is missing bashcompletion, even though a bash completion file is in the upstream repo under contrib/mpc- . Steps to reproduce the behavior: the package a terminal and type It tries only to complete with the contents of the current directory mpc should be completed with the mpc subcomands like , , etc. On a regular system, the file would have to be installed under /etc/bashcompletion.d/ . I don't know whats the nix(os) equivalent to this.
First, I am not the maintainer of this package. Nonetheless I will review this. Second, in Nixpkgs we do "almost" the same: we use a special hook that installs those extra files at the . Now I need to sleep; please wait a bit more.
Package name: neovide Latest released version: 0.13.0 <!-- Search your package here: --- Current version on the unstable channel: 0.12.2 Current version on the stable/release channel: 0.11.2 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --- Note for maintainers: Please tag this issue in your PR. As an additional note, I am currently working on updating Neovide myself. Part of my plans this summer are to begin giving at least two contributions to Nix/NixOS/Nixpkgs each week. I intend to begin maintaining Neovide as part of this goal. Gotta figure out how to A.) apply as a maintainer and B.) figure out if I'm even eligible. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
For future issues/prs/etc. where should I add an additional summary/context if I have any? I've sandwiched it between the Note for maintainers... and Add a reaction... sections in this issue.
Evaluation failure when setting and . Moreover setting any will "remove" the default values for and your system with these options: the failure: System builds, firewall is opened for the default 4533 port. This bug happens because the rather than for each individual setting. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
the Issue here is the option being null, you can use these options together if is supplied. if you encountered a different eval failure to this please attach it. Yes this is because those options values are supplied as apart of one default of as a whole, I am not aware of a nice way to give them a default independent of the rest of the settings being set or not. would giving this port value a catch for being null be an alright solution? e.g.. if is not set, then use the upstream default ( of 4533 I believe ) I don't really want to separate out these values from the . option so this wont address the removal of default values when setting them yourself to something different, I think this is expected enough* behavior. I think fixing this eval failure condition with simply supplying the default port where isn't supplied is reasonable enough, as anyone who wasnt going to set that in the first place is unlikely to care if its the same value in function either way. In fact i may just remove the default entirely and simply handle the case of no supplied value by assuming the default port (of 4533 ) in the openFirewall rule. I'll PR these changes once I get the time
This issue tracks the conversion of from Docbook to CommonMark per . If you intend to work on this conversion, please comment below! here that you intend to work on it. (Please also post if you stop working on it.) a new branch of nixpkgs master. : change to . to . the contents from Docbook to . Follow . Use existing sections for inspiration. from the folder to build the manual. the manual on your computer at after running from folder: it looks good, submit a PR and reference this issue.
I will also work on this
Working with large repositories on low-memory systems (such as aarch64-linux SBCs) can lead to out-of-storage scenarios with the github-runner service because the working directory is set to by default , which is sized to 25% of the system memory by default . Ideally there can be an option to use storage instead of memory for the working directory. I'm opening an issue first because I am not sure if there is a way to work around this already; can the argument in the service be overridden, or is there another way to change for this service with a systemd setting? If there isn't a straightforward solution I can open a PR to add this as an option. Maintainers:
I also experienced issues with no space left on . So far, however, increasing its size did the job. Nevertheless, I'd also appreciate the option to use another filesystem for the runtime directory. We won't be able to use systemd for that as it demands a -like filesystem for the runtime directory.
I guess standard installs avoid this by using the directory. Maybe we should just document how increase size instead of adding another option?
You may pass an arbitrary path to the options of the configuration script. Our module currently always uses the runtime directory systemd assigns to the service.
Yeah, in our case using the runtime directory that provides makes the most sense for dynamic user, again, with documentation on how to increase the size of the runtime directory. Currently our module doesn't support static users so isn't very useful... though I'm guessing our lack of support for static users is an oversight - see details here:
Project description mouse macro Actiona is a task automation tool. It allows you to create and execute action lists. You don't need to know any programming language to use it: its intuitive interface allows you to create action lists (scripts) using drag & drop. Advanced users can use JavaScript (EcmaScript) to extend its functionality. Actiona is free software and runs under Windows and GNU/Linux. Binaries are available for Windows and Ubuntu for both 32 and 64 bits. The program is developed in C++ and uses the Qt framework. Metadata homepage URL: source URL: license: gpl3 platforms: cross-platform
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .