jiebi/CodeConvo huggingface dataset:
"/nix/store/7h5p0sd7acqvsw4jj4jygncmsq6sdcsq-wayland-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/a1b3p02cm1gsy16jwlgg00x9k3kp182r-libpulseaudio-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/pcs9vp9pcc2vqzvpjddqf7ifv951j323-libva-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/9a417mnzmkz7nbdq3kqpa5520qlggxga-vulkan-loader-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/5fpv8x3f6yzw0aqrslv3q126xx48lbn7-gtk+3-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/pwl7ygmix3skcz8xqz4pcm620vpr8bd5-nss-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/2nkjrh3za68vrw6kf8lxn6nq1dval05v-gcc-10.3.0-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/xnqj2w9szfw5mfwylhlavgxkiv9rslmg-sane-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/ldibnigsg44q3wp6v8ikn8kq08lf675c-glib-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,
"/nix/store/bn7b7cidb9qgs8m8y83nf247j8j3xjsf-pango-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/q42c9s1cbyg5inf8ranys485akhaxh3v-cairo-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/w259jz35i221vil0jg2dpdw3zda55ai4-libX11-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/zbrzcprzpcby9107v8xkph2wks3mk93r-atk-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/pwl7ygmix3skcz8xqz4pcm620vpr8bd5-nss-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/5md0fgrd9jir7wdnxla46dfcb15vdsm2-nspr-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/cfv850gaqmzrs60fpxxkv088zcj74hi3-libXext-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/fgdh05bisfqs9llxvsg4c66ag9l78b58-libXfixes-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/lbignzjfjydc4zb1d6qal3sjq7km3pqf-libXcomposite-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/l9s8gcnh687p4cpkj0ic4ym180lpy9an-libXdamage-",
ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/cgg7sv3aa40mksfrm44rfifcgprgd25v-expat-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/zdmma38hz9jjks3dsm8qsmr006lnl0dp-cups-2.3.3op2-", ORDONLYO_CLOEXEC <unfinished .</pre</details
Temporary solution: or or, on flakes,
BTW, same problem with the . Vulkan backend only worked with the trick above
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Unfortunately this is still broken for me
This is still broken
Oh, seems like part of the issue is Vulkan is not supported on wayland yet
It's an upstream issue at this point, due to there being no Vulkan support on Wayland/Ozone:
Project description A simple one-file way to run various GGML and GGUF models with KoboldAI's UI. Metadata homepage URL: source URL: license: GNU Affero General Public License v3.0 platforms: darwin, linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
should be similar to llama-cpp since it is a fork but idk enough about both projects to do it myself
I'm currently working on this, although for to be packaged will need to be merged.
On or cross-compiled from , breaks: From : You can either run this on another architecture using . or should not crash: This was responsible for failing to replicate datasets to my ARM NAS. The issue does not_ occur for natively compiled builds. It appears to be a cross-compilation issue only.
It is a bug in / derivations. In non-cross cases it gets copied from used to bid into output: But in cross-case used to build does not yet provide as it needs bits of for it (and the library path is slightly incorrect). One of possible workarounds is to try to add to to get it pulled via from expected location.
We don't do the copying to glibc anymore, but this error still occurs as described on current nixpkgs master.
Yup. cross-compilation never propagated to in any form (and does not today).
Could you please try this PR? It should fix the problem.
With that PR, I'm seeing this on both (a Raspberry Pi CM4) and with QEMU on : Log from aarch64 machine: Log from machine with QEMU:
Well it's finding now, so there's clearly some other problem with addition to that. When I run it with I even get line numbers from inside : That line () is the last line in the following snippet of code: ... so is deliberately ing here due to . Grepping through the docs turns up: This is happening because uses . Once you do that, glibc needs to unwind the stack frame of any thread that calls . And unwinders are a giant headache. I'm afraid that's all I've got here. I've removed the closed-by from since it was only part of the problem here.
Ah, I think I know what it is. We can compile a without , but it won't have an unwinder. We need to pass the glibc headers to the build in order to get one of those.
would you please try ? I believe it fixes one of the two problems which caused this issue, and it includes which fixes the other one. It works for me: BTW, this issue (cross-compile , then run it under qemu) is a really valuable test case. We really ought to add it to so Hydra will catch any regressions automatically.
Especially since the failure mode gives the user no error message to help them troubleshoot the problem! is a great candidate for this since it's one of those very rare non-C++ programs that uses advanced stack-unwinding features from pthreads.
Confirming fixes the issue. Tested with both and on real hardware and with QEMU on x86_64.
~I think this is fixed, and more cleanly,~ by Edit: it is not. :frowning_face: I will keep trying. Test is in Currently building.
Added this to , but commented out since it is not fixed yet.
The option is declared as "list of packages". To me, it seems too restrictive, since it prevents useful configurations where web applications are copied from some mutable location in the filesystem, like this: . (Note that for tomcat's virtualHosts, the similar configurations are accepted and work fine just fine! I'm going to use them on my server.) Moreover, the current type was possibly chosen without much thought: it was a part of the long commit which mass- type specifications. My proposal is to change the type of from to . Right now, this kind of configuration produces an error: system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:
Project description Pantheon Tweaks is a Switchboard plug allowing users to somewhat tweak Pantheon (elementary OS's DE) settings of the more hidden kind, not normally available from Switchboard. As NixOS has Pantheon packaged, it might be of use in Nixpkgs. Metadata homepage URL: source URL: license: platforms: same as Pantheon Depending on Pantheon version currently in Nixpkgs, the predecessor elementary-tweaks, also GPLv3, might be of more use:
As I maintain Pantheon in NixOS, I approve of this being packaged in the future, but not , because it's archived and IIRC I denied that .
Then we should probably do it once Pantheon in NixOS advances to whatever version elementary OS 6 Odin will have - this'll probably happen once elementary OS 6 will get released.
Ah yes, the repo says "Pantheon Tweaks is currently only supported on elementary OS Odin" :+1:
Did some initial work for this (), would you like to try that? Will need Pantheon 6 () and following line in your NixOS configuration file: Update: I will move this out from the pantheon namespace when creating the PR due to reasons below.
Did some initial work for this great! would you like to try that? of course works great. only the force darkmode did not work in minder program. haven't tested more... ! ! maybe it could be enabled by an option like ? So it's consistent with other options like .
Tested 1.13.1 on both elementary OS (installed via appcenter) and NixOS (btw minder in Nixpkgs seems out-of-date, just opened a PR: ), I guess this should be an issue to minder, as minder is trying to read information from of granite (, ), so it should respect settings from switchboard-plug-pantheon-shell, while what pantheon-tweaks does is (I guess) setting under you gtk config file and I am not sure how handle this. You can check this with: ! I am not sure as this is not an official part of Pantheon. I guess it should be okay to do this.
I am not sure as this is not an official part of Pantheon.
yes, that is a concern, but we can make that clear in the description do you think it is acceptable to enable a third-party component (e.g. pantheon-tweaks) with an option like if we clarify that it is third-party in the description, which is for example displayed at the or in the documentation?
I would not recommend packaging this tweaks app. It regularly breaks since it references gsettings that aren't considered API. That's just my personal opinion though I'm not familiar with NixOS options or what that means so I can't really offer an opinion there
thanks for your opinion! the program exists and people want to use it and we at nixos want to empower users to do what they want, even if the choices could be considered bad, like installing proprietary software. that's why it's considered for advanced users. you are responsible for the choices you make and you can end up with a broken system, but it's easy to roll back to a working state. experimenting is encouraged So i think it's fine for us to offer the package, but we can clarify that "it's not recommended by elementary because it regularly breaks". I'm not familiar with NixOS options or what that means so I can't really offer an opinion there i try to explain quickly: on nixos the whole system is configured by one (or multiple) config. file. as a consequence is read-only if you want to use pantheon, you add this line to the config: that sets up pantheon with default settings. there are options to change those default, like to remove default apps you don't need... so the question here is, all current options with in the name relate to official pantheon software, but would relate to third party software, which is not visible from the name. so it might not be 100% clear all the time so my suggestion is to clarify it at least in the description of the option that it is third-party and not recommended the concern is that it could devaluate you branding like the name "pantheon"
ah okay yeah. If possible then it would great if that was not namespaced with actual parts of pantheon and instead namespaced the way you would hand extensions or apps if there's no special convention for extensions. Thanks!
i suggest then
Commit introduced type specification for (which was absent before), but this specification is wrong. From within release-18.03, import the tomcat module from the master branch, and create a minimal Tomcat configuration that uses : And see it fails: When using the native module from release-18.03, everything works. system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:
It's only semi-related, but why on earth is the type of a list of packages, and not just a list of paths or strings?? It severely limits the configuration options for no apparent gain.
For the record, was an issue about overly restrictive type of .
use instead of pulling the windows zip from github releases
I can review if you want to PR this
upstream has said that they'd rather us use the github mirror that they're going to set up
the github mirror has been created
Sorry, I have to delete the github mirror, due to bandwidth limits. Please use
the "SRB22.2" branch and/or "SRB2release_2.2.13" tag
Getting 500 errors when trying to access
does this work for you?
The link works however the download buttons don't. PRs welcome if anyone can get it working, but wait for to be merged first to avoid merge conflicts.
i have had another look, and have found that it might be better to pull directly from branch
Thanks, was able to get it to work with :+1:
Kdenlive build fails because CMake can't find QtConcurrent. Error: It appears to have been broken by some changes made to qtbase but I am not familiar enough with it to know what specifically. Changes between success and first failure: Latest Hydra failure: cc Attempt to install Kdenlive System: NixOS: 17.09pre107928. (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: "17.09pre107928." Sandboxing enabled: build-use-sandbox = true
You need to modify the to We should send a patch upstream. This must be a required change since QT5.8.
Fixed by:
Setting nixos option to null, which is legal according to typechecks results in an invalid disk size value passed to Launching the script, aka system build attribute , will throw an error at the disk creation stage mentioning an invalid argument for the size parameter. Steps to reproduce the behavior: new flake output attribute with value of basic nixosSystem option attribute ./result Launching ./result will create a qcow disk and launch qemu with the machine configuration. I found this bug through changes in nixos-generators. I've created an issue in their repo first, but their changes might be technically correct. REF; No maintainers list within that nixos module file. Pinging as last change author on the type of virtualisation.disksize. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't remember why I've set this option to . From the commit that it () it's clear that null is not handled, so it's probably a mistake.
Just stumbled upon this issue and agree with the analysis here. PR at
Project description Hashlink is a virtual machine used in Haxe/Heaps game projects. This is the same stack that shiro games and motion twin uses to make things like Dead Cells and Northgard. The full steps for installing heaps (which goes through dependencies) can be found , and one of the steps is to download hashlink and put it on the path. Metadata homepage URL: source URL: license: mit platforms: linux, mac, windows
I am on it, will try to compose a first draft. :-)
That was fast! I really appreciate it! I put in a few haxe-related package requests today, I'm so surprised no one else has requested them before! But once they're in we'll be happy! Not really looking to nix-ify my haxe projects yet since I imagine it'll be involved, but getting hashlink on the path in a package is a step in the right direction right? :) Really appreciate this, thank you!
I'm not really familiar with the Haxe ecosystem, but the Arch build for Hashlink suggested that this packaging task seemed simple enough (no complex build system, just a Makefile, no dependencies on other parts of the Haxe ecosystem) so that I could do it. Glad that I could be of help. :-) Thank you for your issue contributions! While the pull request is not yet merged, you can use hashlink as follows: (Be wary that commands like this can cause the execution of arbitrary code, so in principle one should use these only with trusted repositories.)
Thanks for your hard work!
how are things going with the PR? I think someone has asked a question on it, I don't know if that means that it's stalled from going in? Thanks again!
There are in fact issues with hashlink on NixOS I think - I think there's some libraries that are build with hashlink that are unhandled - there's an issue for this already as hinted in your PR:
When running OmniSharp, the program is unable to find a dotnet runtime to use at all. When I remove the part from the part of the script, it starts to work. Presumably because moving the command to /dev/null just isn't helping at all? ! !
Oh this is an issue with buildDotnetModule. I was looking at nixos-23.05 when I am on nixos-unstable.
So I am not the only one having this issue I talked about this in the PR that introduced the bug (). I have made a proof of concept for a fix: I will open a PR for this, now that I know that I am not the only one experiencing this.
Your fix worked because, because the original code is checking whether you have dotnet installed by checking whether has an exit code of 0 (which it does, if it is installed). But if you change it to , it will always have exit code that is not 0 (because running is not correct by itself), thus making it think you don't have it installed, which means it will use the hardcoded dotnet 6 version instead.
Yeah, I just stumbled upon it while copy pasting the script manually, I didn't take the time to understand what was happening, still new to shell-scripts. Thanks for hopefully finding a solution!
shogun fails to build since the eigen 3.4.0 bump: The package is a likely candidate for removal. Upstream is unresponsive and development has halted. Removed from debian: Removed from fedora: Blocking vcpkg update: Please run and paste the result. Maintainer information:
I think you were the last one to modify this package, so please speak up if you need it. Also pinging Last call - if no one responds within the next week, I'll open a PR to remove this package.
Yes, I was working on making it build on Darwin and adding it as a Python 3 module. Well, I did, but I didn't feel motivated to create a PR. As you comment, upstream has been inactive for almost a year, the latest release is several years old, and it becomes harder and harder to make it work, and the patches would start to accumulate. To make it work on Darwin we need two upstream patches that fix the build with newer compiler versions. In the current derivation, the Python interface is not built because the CMake flag is not the right one. When enabled, Swig 3 is used to generate the Python interface, but Swig 3 doesn't support Python 3.8+ (and with Swig 4 just fails). It can be fixed with a patch, that feels more like a hack, intercepting the Makefile build, so I am not happy with it: Another small patch is needed to fix the deprecated . Also, I wasn't happy that adding it as a Python module will recompile the entire library again, which takes too much time IMO. I haven't checked if it is possible to build with Eigen 3.4 because it takes forever to compile. It could probably work on the development version. Note that the development version doesn't support Eigen 3.4 because of this, but it may work: But there is no such limitation on the 6.1.4 release, which probably means it would require another patch to fix the code, if somebody figures out. So, I'd argue that the package is too old now, and the derivation has too many issues, and it's too much of a hassle to maintain it, so it's probably better to just remove it.
I decided to sit and take a look at the error, and I actually fixed it.
I don't really use Eigen but the patch makes sense. So, I can send a PR to keep this package on the repo for another cycle at least. I mean, I already did all of the work and it builds. Other distros end up removing it because nobody cares to maintain it.
Nice! Thanks for looking into it. Like you said, if you've already done the work to get it working I don't see why not. If it's too much work to keep it working in the future we can always revisit this and drop it.
In NixOS VM tests, service sometimes fails to start. This breaks e.g. GlusterFS tests. Steps to reproduce the behavior: Building — GlusterFS service fails due to dependency on RPC Bind service. See also Some result related to GlusterFS. Have not yet had time to bisect and determine what's going on.
Hey, I started down this path looking for an updated Glusterfs package, then found the paused PR, which linked here. Fortunately, I think I know the root cause. As you noted, the failure is due to a dependency failure on - the error message in journald is: This was sort of confusing, but I found that led me to . The NixOS config includes: L /var/run - - - - ../run So my suspicion is that starts before and can't check for the lockfile. Since there's no unit, which was my first guess, I've instead been adding and tied to , which makes the tests pass. The diff that makes this work is: Obviously we should probably make this fix in NixOS proper, but I want to double-check with you that such a wider-impact change is safe to make. The proposed global_ fix for NixOS would be: thoughts/feedback? I can PR the fix if this all sounds right.
The real problem is that I am competent about neither rpcbind nor systemd-tmpfiles (otherwise I would try to write a more sensible complaint). Maybe PR the change (if it indeed fixes rpcbind judging from logs + fixes GlusterFS tests + doesn't break any NixOS tests that passed right before) and see if more competent people show up? It does feel to me that ideally tmpfiles should not depend on rpcbind and if they do (dunno, because we have /tmp on GlusterFS???) we are doomed anyway…
You and I are in the same boat, friend :joy: I'm only rpcbind-aware as it applies to GlusterFS, so I don't count myself as an expert, either. The only reason I feel confident enough to PR a fix is that all the pieces line up here and the passing tests make me think that this does indeed strike at the root cause.
If NixOS is shipping with that tmpfiles configuration to bootstrap , then I think it makes sense for the downstream NixOS module to accomodate how NixOS is handling . So my initial instinct of patching upstream probably doesn't apply since distros are probably handling differently. I'll PR the change and we can see about additional feedback for us.
I'm feeling pretty confident that fixed the rpcbind problem - are there any nixosTests that should be re-enabled now that rpcbind reliably runs? I looked around for disabled tests but am not sure where those might live, if any are still disabled. Otherwise, I think we can close this :crossed_fingers:
(looked at the tests, doesn't look like there is a ton of disabled ones)
Describe the bug Epiphany crashes on startup with a bind mount error. To Reproduce Steps to reproduce the behavior: epiphany Expected behavior The browser should startup Additional context Error: exists and opengl is enabled I bet is relevant Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Maintainer information:
I can't reproduce this on my machine. Can you try running it with ?
Thanks for responding. I think this is the relevant part from :
Ah, this only shows that emits the error message. To trace what it actually does, could you try adding the flag?
I just piped it all into here:
The output got cut off there, unfortunately. Maybe you could just attach the text file directly to your reply?
Sorry about that, here is the file:
Thanks for the log! I think I've found the culprit. I've opened which seems to fix it - please try it out.
Package name: tailscale Latest released version: 1.72.0 <!-- Search your package here: --- Current version on the unstable channel: 1.70.0 Current version on the stable/release channel: 1.66.4 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Grocy does not properly save manuals for equipment The issue appears to be introduced by in a patch applied by nixpkgs. Changing that hunk to: Fixes the issue. I'm not currently setup for making a PR, I'm a bit busy, but I wanted an issue for other people to find if they run into the problem. grocy in nixos configuration (admin/admin is default) a new piece of equipment and attach a PDF manual to it to download manual; it will fail system: host os: multi-user?: sandbox: version: channels(aidenn): channels(root): nixpkgs:
appears to be the maintainer.
I marked this as stale due to inactivity. &rarr;