jiebi/CodeConvo huggingface dataset:
&rarr;
I'd still like to see this, though largely for much the same reason Andrew mentions at this point -- I've started working with zig and being able to test cross-compiled macos binaries would be brilliant.
I have got most of a Darling build file running, but I have found an interesting issue. Wever I build I get the following error: From this cmake file: As far as I can tell, the command is a special MacOS thing, and I unfortunately do not understand CMake well enough to fix it...
Well, turns out the issue is that Darling relies on git-submodules, and it looks like this must be built against the Git repo directly, not against the released tarball...
What would therefore be a derivation?
What do you mean It's just a with .
I tried to re-package the prebuilt deb from darling GitHub releases. Here is the nix code darling- Save these 2 snippets as and darling-, then run . With 2 problems: needs setuid/setgid perms, while nix-build would fail if dpkg-deb -x executed directly. I use fakeroot to ignore this problem. always fails. I am not a darling expert, have no idea.
Ah, fantastic, thanks! Looking forward to having this in nixpkgs anyway, but let's see how we go there.
It could be named when entering Nixpkgs.
Good suggestion. I've edited those two scripts.
I got as far as finding out that darlingserver doesn't start with that script because it expects /usr/bin, so updating my to a version, the next issue was that darlingserver was trying to mount overlayfs on "lowerdir=/usr/libexec/darling,up" (may be incomplete, this is strace output) which did not exist.
After a bit of tinkering I got Darling to build from source. I opened with more info. Please give it a try!
It seems that they now use instead of the kernel module. This would make packaging easier.
What's the purpose of ? If it is only the sandbox part of Darling, a new name like would bring less confusion. Update: Opened PR to do the renaming.
Describe the bug Starting slack doesn't show the window in 8 out of 10 runs To Reproduce Steps to reproduce the behavior: Expected behavior Slack window should open Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. 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 system: host os: multi-user?: sandbox: version: channels(ymatsiuk): channels(root): nixpkgs: Maintainer information:
Project description CoreCtrl is a Free and Open Source GNU/Linux application that allows you to control with ease your computer hardware using application profiles. It aims to be flexible, comfortable and accessible to regular users. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux
It looks very complicated. I will look at AUR.
sorry for the late reply thank you very much for looking into it :relaxed:
Well, I will do what I can do. I am not a huge user and packager of such graphical things, but it looks an interesting project to take on. I will do some research.
In the latest stable release, the package fcitx5-openbangla-keyboard does not work. OpenBangla Keyboard package is installed but it does not integrate with fcitx5. fcitx5 crashes every time after logging in.
Here are some screenshots. ! ! !
Thanks for reporting, will take a look.
... Here is my !
Any update? Thanks.
fcitx5 crash log:
I have forked the OpenBangla Keyboard from the develop branch. After the recent commit. it built successfully in NixOS. I am now using OpenBangla Keyboard with an overlay from OpenBangla Keyboard's develop branch. !
I think change of these two lines according to this image will solve the problem. ( I don't know the correct hash = sha256, I just gave this and the correct hash was shown in the build error!) !
Thanks for looking into this. I've pulled the relevant commit and also tested at runtime this time, it does not appear to crash and outputs text properly.
openbangla keyboard installed from the unstable channel does not integrate with fcitx5. It installs just fine but does not integrate with fcitx5. Fcitx5 does not autostart too. OS: NixOS Stable DE: KDE Plasma !
Openbangla keyboard from unstable channel does not work in the unstable nix os installation too. Openbangla keyboard crashes fcitx5 and even if it is restarted switching keyboard layout says openbangla keyboard not available.
When you set , although it sets the CMAKE flag correctly the resulting package isn't actually built correctly as cmake can't find cuda so it unsets the flag. This is due to the incorrect usage of instead of when building the cuda related packages. The correct usage can be seen in the package. It also tries to build with CUDA by default which is wrong. Dlib hasn't supported fftw since however there are leftover references to it in cmake which might lead people to think it does support fftw. fftw should be removed. As mentioned in this it makes more sense to have as an input into rather that so that people can override it with other BLAS implementations e.g more easily if they want to. The package was also missing lapack which should be . Steps to reproduce the behavior: Build the package, it tries to build with CUDA by default. I made an example with a fairly simple nix flake that let's you switch between my patch and the original package. I have created a which fixes these issues. For it to build with CUDA. How CMAKE fails ! For this simple c switching from my fix to the original bugged package on 23.11 before openblas was . ! Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Thanks!
to newer version to different directory as under postgresql user Output I get:
The NixOS service module for PostgreSQL, for some unfathomable reason, initializes new databases using a non-standard superuser role name ( instead of ). This makes it a nightmare to get to work right, so forget that. Instead: back to your old version of postgresql root, dump your entire database to a file somewhere: to the new version of postgresql root, read in the database dump: (you'll likely see an error go by about the role already existing, you can ignore this) For good measure I went and tested this upgrading a 9.2 database to 9.4 under NixOS, worked fine, the applications using it continued on as normal after the import. That said, the real issue here is: why are we initializing databases using a non-standard install / superuser role name?
cc
See regarding the superuser role name.
Shouldn't we switch the default user to "postgres" on new databases and keep the "root" account around for existing-ones ? See
I strongly agree we should switch the default superuser to . Currently, it seems impossible to use to upgrade postgresql databases due to NixOS using the superuser: simply refuses to run as root.
The approach given by above doesn't work for me:
I can submit the change as a PR but don't use postgresql and it needs testing. Feel free to steal it and do the upgrade process with it.
pgdumpall tends to e pretty useless if you database isn't tiny_ :(
that would be a good start :)
there you go :)
FYI: I've just tested migrating 9.2 to 9.6 using and it works flawlessly.
Ok, I think I found out why wasn't working for me, like I mentioned in It seems to be due to this line in the Hydra module: If I change the mapping to then the command works fine. But I'm not exactly sure what are the implications of doing this, or why was mapped to in the first place...
In case someone runs into the same issue as me, I am documenting the procedure I used to upgrade a PostgreSQL database that was being used (only) for Hydra.
I tried to follow procedure above, but as I mentioned before, to use as suggested I needed to change the PostgreSQL user mapping in the Hydra module as specified in my comment just above this one, otherwise I would get a message. However, to read the database dump back into the new PostgreSQL installation I had to change the user mapping as follows: ... and then, after activating the configuration, I needed to run the command in the following way (as root): After doing this, the upgrade from PostgreSQL 9.4 to 9.6 seems to have completed successfully.
Related
If anyone else stumbles on this, pgupgrade seems to work now. I realized after upgrade that my db got reinitialized, so steps for me were much more brutish than that post, but in a nutshell: with new postgresql running, clear whatever got reinitialized (pgupgrade won't run if there are data around, but won't tell you what to remove... lists databases, don't know how to list users, I guessed) drop database whatever; drop user whatever; stop postgresql.service figure path for old binaries, e.g. and copy it somewhere. run the actual pgupgrade as user: restart the postgresql service if all went well after some testing pgupgrade suggests removing the old db with (disclaimer: Don't blame me if that eats your data)
I get errors like: This shared object is provided by derivation, not i.e:
Just some additional info: using the wrapper script provided by doesn't solve it either.
I would like to hear from someone more experienced, but maybe an aggregate package (like for texLive) could solve this.
You are right. I was talking about the PulseAudio plugin simply because I believe that it is the only plugin used by almost everyone. Other plugins are kind of “special”, or “professional” and can be dealt with on per-expression basis, but the PulseAudio plugin should work out of the box without any extra configuration from the user or the expression maintainer.
BTW I just found this topic from 2009 with a relevant discussion: An aggregate package seems to be a viable solution. The problem with this (which seems to be the one concerning in the ML) is that adding plugins won’t be possible without rebuilds.
It's really tricky because ALSAPLUGINDIRS is a compiletime constant in alsa-lib. (so the env-var approach won't work) I tried to add a dir for plugins like for the graphics drivers to /run/alsa-plugins. The problem with this is that alsa-lib builds smixer into ALSAPLUGINDIRS so it has to be inside the derivation. You can pass the configure flag --disable-mixer an then alsa-lib will build, but then gstreamer won't build anymore (i guess it tries to link against the smixer in alsa-lib). I haven't tried the aggregate package yet because I'm not sure how to make everything use the aggregate derivation instead of the alsa-lib.
By the way, looks like should be removed. Looks like there used to be a in Nixpkgs that made respect this environment variable, but now it is .
Shouldn’t the commit that removed the “unused” variable be reverted? I mean, we need a beautiful solution, but at least it worked before that.
All the plugin so-files are relatively small in comparison to libasound (<300 kB together vs. ~1.4 MB), so we might consider having the default attribute contain the plugins needed for pulseaudio playback. Our attribute no longer needs to build, so we should be able to reverse the dependency and make depend on . /cc should know more about pulseaudio packaging. Perhaps it's a similar situation in there.
I was thinking about integrating the alsaPlugins into the alsaLib derivation altogether. (I need the jack plugin as well) It may not be an elegant solution but it's not that big an overhead (maybe some dependencies will need adjustments) And build all the plugins that are buildable. Also I think the workaround was removed in official alsa project. See Dynamic Loader helpers section here:
I'm using this workaround right now:
Also see , which maybe adds more complexity to this issue because of a 32-bit library / 64-bit plugin mismatch.
(triage) status?
I think I'm seeing an effect of this in attempting to update the Factorio derivation, but master nixpkgs has a more up to date version of alsaLib, but it appears to be trying to load the plugins from the system installed version of alsaPlugins.
I also got hit by this issue while trying to run Nix-installed Audacity 2.2.2 (from nixpkgs master) on Ubuntu 14.04. Audacity playback doesn't make any sound because, it seems, hardcodes its plugin search directory.
I worked around this by creating a directory containing a symbolic link to and adding that directory to .
I've found a workaround in Guix manual alsaPlugins the following lines to ~/.asoundrc or
Wow. Thanks for the tip gnidorah <:
Still relevant in 19.09 :/ Does anyone know the syntax for importing rate conversion plugins ("speexrate", "samplerate", etc.) directly inside "", or if there's a method without hackery by now? Btw, seems to be affected by this, I'm using your workaround from here right now, together with .
Meanwhile it is even ALSAPLUGINDIR instead of ALSAPLUGINDIRS (notice the missing plural 'S')
we could patch like so. But beware, this is actually only for the the second time that i am patching c code. I tried it with and the converter and it's working so far. <details<summaryenvironment-plugin-</summary</details
Or we could just bring back the original patch.
i guess it is still here (somehow :)) but it is doing nothing for loading rate converters since they are neither loaded through patched from nor through from but through from But yes, now that i reread your comment, that way of telling alsa where to find libs is gone.
Since I opened this issue I'm not sure what to do with it, but since learning more about alsa config this is no longer an issue for me. I'll post my config hoping it helps people: I have in my And my config looks like this: This finds the jack plugin just fine due to the If I want to run something (for example steam) that won't be able to run with jack then I just fallback to my mixing PCM with stopping jack exporting
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
This still needs to be addressed (either by the wrapper or by patching the package, maybe both). I've been using the same trick as and it works well enough, but it'd have been great to have the package itself or the wrapper handle users' additional plugin paths out of the box.
With the release of v1.2.4 on 19 Oct, alsa-lib gained official support for an runtime environment variable. It was in , following with some Guix folks. Note that this environment variable only supports a single directory, unlike the (effectively unused?) alsa-plugin-conf- which provided a plural environment variable.
One nice effect is that we don't have to patch alsa-libs any more. Thoughts on how to best take advantage of the new feature?
Without writing an updated patch for multiple plugin directory support, the upstream's can probably be put to use immediately by pointing to symlink farm of plugins. Haven't tried this, but I suspect it (or something similar) would do the trick. The linked GUIX thread included review of a patch for multiple plugin directory support. It looked promising but its growing stale with outstanding feedback. They've not responded to news of upstream ; I do wonder if they'd consider contributing their multi-directory patch or not - especially given that there's now some kind of upstream support.
Guix's property will automatically create a create a symlink union of the relevant plugins for single-entry search paths. It's how Chromium extensions and plugins are discovered, for example. It's just because we haven't gotten around to update alsa-lib yet, as it missed the latest 'staging' cycle.
Hi, I'm the author of that patch from Guix, although it grew out my reading of the old unused nixpkgs patch. I ran out of energy for keeping track of all the "C issues" one has to think about... if alsa-lib's new ALSAPLUGINDIR meets our needs then I'll be glad to leave the patch behind. Feel free to use the patch in any way you like — it does work fine and, as a part of Guix, the license is GPL3+. Or, as a part of alsa-lib, maybe it's LGPL2.1+? Anyways, feel free...
I marked this as stale due to inactivity. &rarr;
I implemented the aggregate package approach () and appreciate your thoughts on it.
Package name: Latest released version: 1.1.0 <!-- Search your package here: --- Current version on the unstable channel: 1.0.0 Current version on the stable/release channel: 1.0.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 Note for maintainers: Please tag this issue in your PR.
Packaged VLC does not seem to support wayland. Steps to reproduce the behavior: vlc with on e.g. sway opens as a XWayland window VLC opens as a Wayland native window Not applicable Possibly related to VLC not depending on qtwayland. Please run and paste the result. EDIT: Typo
It is strange. I built it and verified, it is not linked with QT libraries even if they are put as inputs.
Is also pulled in as an input?
Nope. Working on it now. First encounter: Wayland is considered experimental and disabled by default.
Can you test the patch?
Works like a charm, thanks a lot! :)
I'm on NixOS 23.05 and discovered that vlc prefers to use XWayland if var is set. If I unset then vlc starts in Wayland mode. Does anyone know how to make it to start on Wayland by default?
For now I hacked it with: Special thanks to
Well, if this is hardcoded on VLC, there is nothing to do (besides maybe searching some hidden commandline flag).
The "use QTQPAPLATFORM be damned" behavior is apparently just what QT does, and is not specific to VLC
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Here is the updated wrap that also addresses the desktop file
After setting up faster-whisper for my Home Assistant instance, I learned that my CPU (i5-6500) isn't quite as fast as I'd like for this, so I am now trying to test a GPU (NVIDIA Quadro M2000). My configuration for it is the following: I expected it to then run on my GPU using CUDA, but unless my GPU and CPU are continually equally performant, it is not working. (Also, no processes are shown in ) Steps to reproduce the behavior: NVIDIA GPU, and then configure it accordingly in , add , , , and to faster-whisper in configuration, configure it to work with device = "cuda" for STT to be faster, instead same speed I'm not totally sure what to expect because this is my first time using this, but I expected a Python3 process to appear in and for my STT to be quicker. My config is the following: The following (seemingly) NVIDIA related items are at /dev/ ! ! works, but I am not totally sure that my CUDA is configured correctly, for all I know possibly CUDA isn't configured properly, but I think I have everything correct.
I eyeballed CUDA support, but have no hardware to test or reproduce. I appreciate help in fixing the module to make it work with CUDA.
I am not overly proficient in Nix or anything like this, but I would be willing to help if you have ideas.
Well, for one we're not passing in . Can you try setting ?
Ok, I that and now when looking at the logs, I get this: It then exits.
That looks actionable. We did indeed not build ctranslate2 with CUDA support. I can try to set that up, but it won't be the default, because that would make the package unfree. We possibly need multiple ctranslate2 attributes.
Is it possible to have the package be free unless an option is passed that enables CUDA and then makes it unfree, or would two different packages be needed. There could be a package, I think that could work.
Yeah, that would also work.
If you want to try and build it with CUDA support, I can test it out and report back.
fixes the module, so it passes as expected. It also adds CUDA support to .
Check the description of the PR on how to opt into CUDA support in nixpkgs.
Hi Just to clarify, you only need in your (or in your 's ) if you're setting up a development environment to write cuda programs. If you only want to use packages with cuda support enabled, you just use them directly (e.g. ), no need to add anywhere manually. If you want to enable cuda in every package that supports it, you can set in your (nb: this triggers a massive rebuild). Instead of adding , you want to use (this way if you switch e.g. -, you'd be still using for the correct kernel), but also instead of you can take (keeps working if you switch e.g. -) Sorry we didn't get this documented yet
Wow, thank you! I assume I still need in my , right? About enabling , I've already enabled that and let it go through that whole process, so I think I'll just leave it enabled. About changing the , how is that to be done exactly? Do I just swap for in the exact same spot?
Also, is there an easy way for me to test out this updated package before it gets merged?
Depends on how you deploy your machine and what nixos version you are on.
I'm on Unstable and use Flakes.
You could replace your nixpkgs input with a fork of nixos-unstable and pick the commits from that PR on top. I'm sure there is a better solution, but I'm not well versed in flakes.
No, is the old version of , and you don't need it in Yes, except it's just , without at the end. This refers to "whatever graphics driver is in use". But also you can just remove this if you use and (both options are badly named, they're not really specific to neither of opengl or x11)
I have , but I don't have xserver enabled because this is a headless server. Do I even need nvidia_x11 if it's headless with no DE?
is where comes from; I don't recall now if it's ok to use on a headless machine, but if you like to just be explicit, you can keep P.S.