Full log: Error message: That's the result I get from my macOS remote builder. When I run the build on my desktop Mac, it builds fine and uses the impure SDK from my Catalina install (10.15.1): However, the local build displays this warning repeatedly: I assume this is related to the macOS patches and hopefully gives some clue as to why it's broken.
qtbase builds fine on hydra: qtwebengine fails:
Those links point to the same thing. Anyway, strictly speaking I'm trying to build , but it's failing in .
Can you explain what do you mean? How are you using ?
It's a dependency of . edit: sorry, I see what you mean now. is a dependency of . I was confused by the message from the build saying that QT would be installed in .
Sure, depends on . Realistically, your best bet for now is to just use anki from an old version of nixpkgs. You see, doesn't have a darwin maintainer. I think, I was the last person to fix it around last January. The problem is that it's hard to keep up with all the updates. Every "minor" Qt version bump brings serious breaking changes for on darwin (like they might not even support our version of SDK anymore...). To make things worse we port all those bumps to the stable branch, so it quickly breaks there too.
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still important to me, many qt apps are broken on darwin due to this one.


Mangohud no longer appears on gnome/wayland when opening a game. "rev": "", (works) "rev": "", (doesn't) Steps to reproduce the behavior: a game on gnome/wayland doesn't appear even when enabled (worked in previous revision of nixpkgs above) ... Mangohud shows system stats Please run and paste the result.
I have the same problem too. I'm using Hyprland btw.
Oh weird. I'll try looking into this. The only thing that really sticks out to me in the diff is possibly ? - but it seems unlikely. I'll do a git bisect to try to narrow it down better.
If it helps you narrow down, here's my repo with the exact commit where mangohud stopped working. If I revert back to previous commit mangohud starts working again:
I bisected it, it's cc
mangohud uses its own internal copy of vulkan-headers: So it's probably the loader? If it is though, it might be tricky to bisect...
So, what are we going to do? Especially w.r.t. 23.05 being around the door. I don't think we should ship a broken mangohud in 23.05. Honestly, I think should have probably not made it to master before branch-off. (Eventhough it was technically merged a few dasy before breaking changes were restricted.)
I'll try to reproduce locally and see if I can bisect vulkan-loader.
cc because of
We could also try updating the headers externally; Mangohud's are really quite old. They use this weird meson wrap thingy rather than letting the distro provide it and it too is very out of date. Also, this is the error we're getting: (This is on 64-bit-only Mangohud.)
It breaks when built with newer headers.
Oh sorry, forgot to get back to this! Maybe we need to switch back to using the system headers?
I'm actually pretty sure it's which we probably don't want to revert, but we may need to look into layer ordering?
oh no - yeah i think you're right, i think the duplicate behaviour was specifically to support multi-arch layers (from what I remember).


If it's just an issue of duplicate layers, perhaps we could add 32 and 64 suffixes to the layer names. obs-vkcapture does that too.
I gave up o pursuing this, as seen in It works, but for this case here, it's probably better to bring attention upstream. Cc
Having only the 64-bit mangohud json in the implicit layer dir works! Going to try giving the 32-bit layer a different name now.
This is also going to affect vkbasalt too then - I haven't tried yet though - I'll take a look at fixing that too!
Speaking of, any reason you gave up on that? I personally really liked the good idea.
Different suffixes work! PR incoming.
It needed a proper rebase+bump to v1.3.250, and I couldn't figure out how to really take a good benefit from it.
Hm, I'll definitely try to pick it up after branch-off then.
Peculiarly, obs-vkcapture seem to do this for some time already: from gamescope might need this fix too.


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!


It got a huge closure size. Jump happened here: 91.1.0: 0.5 G 91.1.1: 3+ G On a quick glance, it's mainly due to dragging lots of toolchain packages, rustc in particular: /cc other likely interested people:
and don't suffer from this, by the way.
This may be relating to ().


Steps to reproduce the behavior: afl <!-- 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]:
If you are planing to open a PR, you don't need to create an issue first.
I wasn't sure, thanks for clarification


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:


dockerTools.buildImage fails with: System: 17.03pre95306. (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "17.03pre95306."


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 .


After upgrading to eww 0.6.0 from unstable I've got problems showing some strings in some of my widgets, one that shows the hour and another the minutes using two digits each one, i.e. : "09 : 10". When using eww 0.6.0 the string shown is like this: "... : ..." In eww's github repo I can see that there is a commit after version 0.6.0: And cloning eww repo with that commit, compiling it and using a local eww executable the problem explained before disappears for me. There's also another problem, asking eww-0.6.0 for version number shows it's 0.5.0: unstable eww 0.6.0 some string truncation (I think this is the problem) see "..." where a two char string with the hour should appear. eww should work as expected. Cloning eww repo with latest commit after v0.6.0 was published solves the problem for me.
~The current package for eww is . How did you install 0.6.0 from nixpkgs?~ ~As for the outdated 0.5.0 version in nixpkgs, there are three maintainers for eww in nixpkgs so it probably will be updated shortly, perhaps fetching a commit with the solution to the string truncation problem you describe.~ EDIT: i was wrong, see comment below.
I got it installed today from unstable when upgrading my system: But, as you say, if I look for it into unstable () it shows version 0.5.0...I can't understand very well this...I'm relatively new to nixos. Ok, I'll wait then. Thanks for your interest in this.
Oh sorry, you're right! There is eww 0.6.0 in master, although it didn't make it into unstable yet. I built the package and, indeed, truncation is broken the version is incorrectly reported So the truncation was fixed, as you mention, after the release, and the reported version . That . If you can't wait, for it, i'd recommend you use the package output from the eww flake.


I personally have been using it for a while and it works correctly (let me know if you need help, i'm on the matrix server with the same username). For now, I guess this issue can be closed because both are upstream bugs and the fixes will make it into a future release.
I think I we can backport the changes using patches. I'll send a PR.
Still I don't know how this 0.6.0 version was pulled from unstable into my system...I'm in my way learning nixos. Flakes! my never ending story :). I'll try to use it and if I have problems I'll try to ping you on the matrix server. Thx!
Since 0.6.0 reached unstable, of course, and you updated your channels/inputs. BTW the search can be out-of-date, so don't expect 100% accuracy from it.
Yep, that makes sense to me and seems to be the missing piece that confused me: how could it be possible that in the search appeared version 0.5 and I had installed v 0.6. thanks for clarifying it for me and for your work in Nixos.


cc
Bisected to
This is an error when calling . We should fix git wrapper.


Describe the bug dmd keeps references to boostrap compiler. To Reproduce Steps to reproduce the behavior: Expected behavior dmd has no references to boostrap compiler Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): nixpkgs: Maintainer information: Note: to prevent future regressions, it would be nice to add to the derivation ()
I marked this as stale due to inactivity. →
Still an issue
I marked this as stale due to inactivity. →


The final merged version of isn't building. Just build with the initial configuration that would give on a UEFI machine, along with: Build successfully and boot into Dom0 on next reboot. <img width="1201" alt="image" src=""During the progress of , the issue isn't happening as of . Might be a regression happened in the last few commits before it's merged. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Whoops. That's my bad. Will make a PR in a few.


Steps to reproduce the behavior: azure-cli Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result.
For now, changing python used to seems to fix the build:
Made a PR that fixes the failure.
Will investigate this failure and try to fix it (by using Python 3.11), but the build was working before (We may temporarily fix it using as a workaround), some dependencies must have been changed, from before, not sure which one is causing this failure, I'd need to bisect commits on master branch, I guess...
The failure is because of python3.11, the tests didn't work properly on 3.11. Upstream fixed those tests for a future release. For now we can either rollback the python used to 3.10, or back port the tests fixed. From what I tested, nothing is broken on 3.11 except for those tests.
Thanks a lot for those clarifications and appreciating a lot your help in fixing all this However, we can't really make sure that those tests won't break again, unless we pin a patch on those ? And this is what you've done in your fix PR. I'll be trying the latest release 2.53.1 with the dependencies cleanup.


Describe the bug The is failing. I bisected this problem to “linux: Init 5.8”. The error message matches , which points to both a workaround of recompiling systemd against Linux 5.8 headers, and an upstream systemd patch (systemd/systemd) that’s in systemd 246 () and was backported in 245.7 as systemd/systemd-stable To Reproduce Steps to reproduce the behavior: Notify maintainers Cc Metadata Please run and paste the result. Maintainer information:
My PR wasn't merged, Linux 5.8 ended up being by someone else.
Linking for visibility: that PR was
The PR bumping systemd to 245.7 is at
Is it really helpful to send systemd 245.7 to given that will be unable to advance without it? Or are you thinking we also want to revert the bump in for now?
Maybe we should revert in master, and re-revert it in staging again. I let and decide about this, they've been doing the staging rounds.
Hey all, question: How do you spot which tests block the channels? I always track and every few days I notice nixos-unstable doesn't progress. When it don't I see an issue with the "channel blocker" label and I always wonder..
Click on the “Hydra job for tests” link and go to the “Constituents” tab.


The postStart script of elasticsearch fails when a special values like or ( ) is used for services.elasticsearch.listenAddress as the script expects an IP or a hostname. Using an ip as listenAddress ist not always a viable option especially when generating NixOS images upfront for a dynamic deployment (e.g. on Azure or EC2) I am not sure how to address this issue. Perhaps one shall check netstat output to find out which ip was bound to? /cc
Yes i agree, we should implement another option for es url, I'm fine even with removing postStart. You can create pull request if you need fix asoap, I will put it on to-do.


Project description The MongoDB Shell Metadata homepage URL: source URL: license: APACHE LICENSE, VERSION 2.0 platforms: linux, darwin
I will like to have it on too but fyi there is a NUR package.
Thanks, I haven't searched in NUR


Package name: hyprland Latest released version: 0.36.0 <!-- Search your package here: --- Current version on the unstable channel: 0.35.0 Current version on the stable/release channel: 0.32.3 <!-- 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]: The 035.0 has a bug that makes my system crash very often (nullptr when monitor is disconnected) the issue is supposed to be fixed in 0.36.0.


After reboot, while systemd units are still loading, if user clicks on Systemd-Manger extension the entire DE will crash and Gnome will force a log out of that user. Moreover, Systemd-Manager is at v14 when v15 is out from the developer. Steps to reproduce the behavior: Computer DE loads and user is logged in on Systemd-Manager (while the systemd units [custom systemd units by the user into the extension] are still loading for example "bitcoind") crashes and forces log out No crashing of DE and you should be able to see in Systemd-Manager the units that have not started without it crashing Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Any news on this? Thanks so much!
Any news on this Thanks so much!
Update should be contained in
sweet!!! Thanks, I will keep an eye on it. Thanks again!
I checked and plus the superseding still contain version 14. The author notes on the that they will no longer be publishing to that site, and indeed the latest version available for download there is still 14. So the metadata for that extension may need to be manually overridden in nixpkgs since it is not going to get the latest from via the automated update process.
This works as a standalone package, for inclusion in you'd probably be fine not declaring ,,. Would be happy to make a PR for it, though it's not something I'd actively mantain/use myself. Just updating the metadata itself wont do, as it would still be pulling from for nonexistent files.
Looks good! That updated package does fix the crash for me.
did you just install the package from nixos?
yes, it seems then having its own package would be the best no?
Ah no, it would need a PR to even get into nixpkgs. I just it to my local config using an overlay.
okay, well I will look into how to overly in a nix file. Also, it is hard to maintain a package? As, maybe I could learn how to maintain this extension if will be unable to maintain it?


Maintaining an extension like this should be as simple as increasing the version number when a new release exists, given it's lack of external dependencies or nixos-specific quirks that need to be patched (there may be some out there). What I meant by not mantaining it is that I do not actively use it within my setup. And I assume these manually packaged ones would need at least a "reference" mantainer to keep it in check and direct issues to.
Thanks for the good info ! Well, I can be the maintainer, but I might need help from time to time. I will use your code if that is okay? So, next steps to put in the PR and then add me as the maintainer. Also, would you want to be on this as well?
piegamesde was only the maintainer of the original extension package because they're the . Manually packaged extensions go in and generally have a maintainer attribute set.
Circling back to this... I would like to be the maintainer of this plugin. However, I have never maintained a piece of software on github and I only have minimal skills with shell and nix configuration files. I have never made or packaged a nix module before. Should this task be reserved for someone else with more skills or is there someone who could mentor me in how to be a maintainer? Thank you all for the help in this.
Added this to extension creator's github :
Okay, I figured out how to add 's code into my existing setup. For all the noobs out there this is what I did it: I did NOT use the "overlay" process in NixOS as describe here: I used the process as described here: This is an excellent write up BTW! Save this link for future use. With these resources in mind, this is what I did. I used 's code and named the file . This naming is arbitrary. It can be anything you want as long it has at the end. Then, move that file into directory. Do this via terminal and you must be the user. Then in my NixOS (not nix) configuration file () I simply into the Then, like always, as root This is all explained in the link above. Limitations: hack does not put the new is in the official repository.


This needs to be done by someone and they will become the maintainer. you use this hack you will have to update the for NixOS whenever the developers of release a new update.
Upstream devs released version 16. Whoo hooo! Here is the .nix to make it work on your local machine. Again, this is not in the main nixpkgs repo. You will have to use this code and follow my "hack"above to get it to run in your local nix install. Thanks again to for the original code.


, CVSSv3=7.5 (nixos-20.03) CVSSv3=7.5 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc Cc
Backporting update that resolves these ().
Fixed in 20.03 and master.


Package name: gummy Latest released version: 0.6.0 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.3 <!-- 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! --- There is an open pull request () by from October 2023, but it has not been merged and later versions of the program have been released since then. I think it is also worth noting that the source code repository of the is no longer available on GitHub. as the repository has moved to Codeberg (see ). Notify maintainers (last updated the package) <!-- 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]:
I updated my linked PR to the latest version.
Thank you for updating it so quickly! Is there a time frame in which we can expect the pull request to be merged by someone?


Package name: gummy Latest released version: 0.5.4 <!-- Search your package here: --- Current version on the unstable channel: 0.3 Current version on the stable/release channel: 0.3 <!-- 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 I've tried to bump the version to 0.5.4. <details<summaryThe build fails when downloading json-poputlate</summary</details<!-- If the result shows no maintainers, tag the person that last updated the package. --


Package name: itch Latest released version: 26.1.3 Current version on the unstable channel: 26.1.3 Current version on the stable/release channel: 26.1.3 <!-- 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! --- The current version is broken since butler is marked broken 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]:
The latest version on seems to be 26.1.3 which is used in the package.
There is 26.1.5 as a source code , but current package uses binaryBytecode


libgtop is not reproducible, since it embed the output of into one of its binaries. See or build on 2 machines with different kernel versions. Report attached since r13y will not keep it, I think: libgtop build should be reproducible. This patch works from a nixpkgs perspective: However, it should ideally be reported and fixed upstream. N/A Maintainer information:
I marked this as stale due to inactivity. →


Description Attempting to install conan with nix-env on Mac OS X errors out with the following message: To Reproduce Steps to reproduce the behavior: Expected behavior As Mac OS X is a supported platform for conan, it's expected that it would install. Additional context This appears to be due to conan's dependency on the python3-distro package, which only compiles on Linux architectures. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(tclemons): channels(root): nixpkgs:


There is about the use of imagemagick in NextCloud due to . Admins may want to disable it unless they are certain that users won't upload untrusted files (which can easily happen by accident if folder sync is active). NextCloud is only passing certain file types to imagemagick but it is doing so based on the file extension. Therefore, an attacker can pass any file type to imagemagick. I have tested this with a PNM image (not supported by NextCloud) that I have renamed to . doesn't get a preview image but does, i.e. NextCloud thinks it is HEIF and passes it to ImageMagick, which processes it as PNM. There are several ways to disable imagick: in the NextCloud config. This will not only disable imagick but also previews for PNG and JPEG (which do not use imagick). in the NextCloud config. This may need manual adjustment after a NextCloud update. the extension for PHP. This also disables it for NextCloud plugins. Option 1 and 2 can already be used by an admin if the drawbacks are acceptable. However, I think 3 is the best option in most cases. has options that disable the other PHP extensions that used to be by default. I think we should do the same for imagick. If imagick is disabled, NextCloud will automatically disable the preview generators that need it. It will also show a warning about that (which is subject to debate in the issue linked above) and there may be some implications for the themes app (which I don't use). Therefore, I think we should keep imagick enabled by default and leave the decision to the admin. We could also add a suitable policy for ImageMagick and thereby disable any file formats or features that are considered insecure. I don't think I could write such a policy and be sure that it is secure (or even "secure enough"). In addition, we will have to keep it up-to-date with newer versions and CVEs. That is why I recommend that we only add a simple off switch. The above information is based on NextCloud 20. I will wait until and NextCloud 21 have landed in nixos-unstable (and on my server) and then test again and create a PR if there is any interest in having this upstream.


Ouch, decisions based purely on a file ext is a behavior that sounds pretty broken to me :/ Optiobally disabling imagemagick and adjusting the config accordingly sounds reasonable to me, so feel free to file a PR. You can ping me for a review or if you need assistance with modifying the module :)
It's ok for what they do with it. It won't do double duty as a mitigation but I guess that was never intended. Thanks. Any suggestions on a name for the new option? Simply ? Should I add any tests for that? The existing tests only test three different configurations so adding one just for imagick seems like overkill. It should be quite easy though. If we want to test that previews actually aren't generated... Well, that's a different story. We would have to automate the web interface, for that. I think the existing tests are only testing the service, CLI and WebDAV.
As imagemagick enabled will remain the default, I'd suggest . Yes, adding a fourth VM test just for imagemagick is indeed an overkill IMHO since those tend to be fairly expensive. I'd suggest to write a testcase in , other integrations such as are also tested there. Right that could be a non-trivial thing to solve. Maybe check if there's a REST API or a way to implement this with the CLI of . But I don't think it'd be worth spending too much time on this if there's no reasonable way to test :)
I think we still want to test the default option in so we will need a second configuration that disables imagick. We don't have to start that VM if we only want to check whether imagick is in its closure. As there isn't any test helper for that, we probably don't want to do that though ;-) see Unfortunately, qemu on ARM is too unreliable for the automatic tests because qemu crashes when started on one of the little cores (i.e. 4 out of 6 times). I have done some interactive testing of the above commit but not an automated run. I will have to find some system that is not ARM, not high-security, not already virtualized...
Qemu/KVM does work if a kernel build or stress-ng is hogging the big cores :) is ready for review.


I to and I return I got:
cc (I had to look through essentially old SVN history to find a reference -- this service is untouched for a long time).
I don't use this service anymore. BTW I've fixed its evaluation in the PR .
Let's not close this unless fix hits master.
can you please test the fix and see if there are any more problems with the service?


Imhex on unstable and nixos-24.05 crashes. Output from the above command: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same as pending to merge
Ah, sorry, I only searched in opened issues.


Imhex failed to start. Steps to reproduce the behavior: -shell -p imhex --run imhex Shows the following errors: Imhex start up normally. Adding -v, --verbose doesn't give more information. I don't know how to either.
Maintainer ping:
Can repro on master, but can't repro if I checkout and build from it, it should be possible to bisect and find out at what point this broke.
First bad commit: <details<summarygit bisect log</summary</details
Seems there's a bunch of upstream reports of breakage with glfw 3.4
This might be fixed with The PR was merged into 1.90.6, but 1.33.2 contains a vendored 1.90.4, which doesn't contain the fix. My guess is that updating from the current 1.33.2 in nixpkgs to the latest version upstream (1.35.3 as of today) should fix the issue, as the latter contains a vendored updated to version 1.90.8, which should contain the fix.
Looks like the PR was closed, are you talking about instead?
Yes, sorry. I got the PR reference from: ... which also references the commit you mentioned.
Still crashes on imhex 1.35.3, which I more or less expected.
After applying both PRs and , finally works on my system with the current . Note: both PRs were needed, either one alone didn't fix all the issues for me.
Solved, marking as closed.


<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: gvm-libs <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 21.4.2 desired version: 21.4.3 <!-- 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.


Describe the bug NetworkManager is a particularly important component and we don't have any tests for it that could block a channel advance. In particular, a change can happen on nixos-unstable leaving users without functioning networking, and while rollbacks are possible it isn't an excuse to allow that to reach production systems. NixOS doesn't produce either. Manual testing is also cumbersome if we want to make a new stable release. Upstream NetworkManager does have some integration testing but obviously not useful to us. I think to start, if we at least had a test that verifies the services start without issues would be great.
Agreed. While developing tests for the multipath TCP module I was surprised to see no networkmanager module. I had some difficulties with the nixos test infrastructure at first because the test infra will by default install a slirp interface () and it messed up the interface naming. Like I would clear but interfaces would still be named starting from instead of . Just thought I would mention it in case the brave soul writing the test is interested in multihoming. (but that's more a concern I have with the test infra).
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 .
Bleh.
I marked this as stale due to inactivity. →
consequences of our inactions


() is an old unmaintained software from 2006. Currently fails to build on due to typing changes: And also on that will need an fix: WDYT of removing instead of patching it? Is it still useful? CC Maintainer information:
Thank you for reporting!


Project description A Wayland-native logout script written in Gtk3 Metadata homepage URL: source URL: license: mit platforms: unix, linux
It's already packaged in nixpkgs-wayland IIRC


Since it's not possible to use PHPINISCANDIR variable to pass additional php configuration. That breaks tools also. To Reproduce Steps to reproduce the behavior: 1 . Install php74 Expected behavior Notify maintainers Metadata
Env variable concatenation should fix it
This was intentional to avoid impure state, IIRC. The expressions we have now are very flexible. You can create a executable to include any configuration desired on the fly like so: nix-shell -p 'php.buildEnv { extraConfig = "memorylimit = -1"; }'. Also keep in mind you can pass configuration via to any instance.
By the way... are you familiar with ? Combine with and you have a really powerful combo that accomplishes what you want and more.
sure, I'm working on this kind of setup for my long running projects and I love it. Just migrated from 20.03 where we haven't soo much options. However, for some short term scenarions (like clone, patch, test, remove) creating nix config is not an option. Most of projects maintain their own and symfony tool use them both for cli and web/fpm without any additional setup and cost. I'm ok to use php -d / php -c , but still ignores custom ini files on 20.09
I didn't know that HPINISCANDIR can have multiple directories, but if that's the case, prefixing it in is fine. I mean, we also do that for many other env vars such as , etc.
Yeah I think that should be fine. I would like and to give a thumbs up first, just to make sure the idea is congruent in their minds. You're still happy if we don't automatically import though, right?
This claim seems interesting to me, I have, probably never seen a project provide a And I've been working professionally with PHP for about 10 years. And from what I can recall I haven't ever seen this before. Even working with symfony components along that way. So maybe some does, but I wouldn't say that "most projects does". I wasn't aware of this either, but from reading the documentation again: It's kinda clear that it allows the variable to be separated as any other like variable. I'm fine with introducing the possibility for such impurity just for flexibility for usages such as
there is backported version also can we merge it too?


Describe the bug Bazel is currently broken on the latest master, tested at . Bazel was built fine back at . I'm currently bisecting trying to find the offending commit. To Reproduce Steps to reproduce the behavior: -build . -A bazel Expected behavior Bazel builds correctly on Darwin. Additional context <details<summaryError log</summary</detailsNotify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:
I suppose this might be related:
It's possible. I reverted , , and but I could not verify that it works because gcc failed to build. <details<summarygcc error</summary</details
perhaps or can provide some guidance here. I'm not familiar with how it's all wired up together in nixpkgs.
What’s the content of that fails?
I'm trying to compare the environment of the working build against the one not working. As far as Nix environment variables go, there are no differences except for these that are missing: However, exporting them does not seem to make a difference.
I've tried several different iterations, I'm unsure how to fix this. Anyone else would like to take a stab at this? Things I've tried: Adding clang to the buildInputs, nativeBuildInputs and propagatedBuildInputs. This was a long shot but gave it a try anyway. Exported the and . Added to the and of the bazelrc construction at line 421. Added various files in to NIXLDFLAGS and NIXCFLAGSCOMPILE I also compared the NIXLDFLAGS and NIXCFLAGS_COMPILE between the working version and HEAD, I did not find anything different.
I am not quite sure what the actual error message produced by bazel. However to debug this, you can do to see what flags are passed to the actual gcc.
This is not set if c++ usage is not detected. See also this bit: If you want to include those manually you need to put them in instead. This can affect C programs however.
proposed to check whether it’s a similar issue than what was solved in (He’s not available the next few days though.)
did fix this?
This should be fixed in


Steps to reproduce the behavior: dosbox-staging on darwin Complaining that alsa-lib not available on darwin I suggest referencing the derivation of in which use to opt-in dependencies P.S. wonder why the maintenance of this package is separated from and Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't have a Darwin machine. Nice. A full log would be nicer of course, but nice nonetheless. Wonder why they should be maintained by the same people.


Project description Turn swipes into words -- "plugin" for wvkbd to enable swipe-typing under wayland SXMO. Metadata homepage URL: source URL: license: agpl3 platforms: at least


Project description Various vim plugins iamcco/coc-tailwindcss coc-extensions/coc-svelte evanleck/vim-svelte


Vulkan/dxvk doesnt work on bottles. Vulkan is working correctly on my laptop as vkcube, vulkaninfo and the game im trying to run on bottles (that i ran thru wineWowPackages.staging + dxvk install from the official archive file) run perfectly. Steps to reproduce the behavior: bottles a bottle for gaming a game. the "directx error" pop up. Also, the dxvk log files say that the "VKKHRsurface" extension failed to load. DXVK/Vulkan should work on bottles. ! Please run and paste the result.
Having the exact same Issue on 22.11pre393800. (Raccoon)
If fails then there is a driver issue. Vulkan wont be able to draw anything to screen without it. When it occurs in proton issues it's usually a missing 32bit Vulkan library. Tho there can ofc probably be other causes
update: using the system wine doesn't fix dxvk either. only running thru the command line does. As i said, running it thru wine on the terminal does work, so something in the bottles thing is not working right.
I found the cause: these hardcoded paths right there: With this extra lines in , Vulkan will work on Bottles: I'm not sure if this is the best way to solve it, though. Tested only on a 64-bit bottle (I don't know if 32-bit bottles need to also link ). .
!!! nice find!


<!-- 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: bottles <!-- 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: 2022.5.28-trento-3 desired version: 2022.7.14-brescia-1 <!-- 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.
While automatic update using was removed by in you need to wait while we will "get auto updates from r-rynatm"
That not true. I removed the over complicated updater in which wasn't necessary at all. Since r-ryantm also uses nix-update there was also no need to replace it. That's wrong. You can always create an update PR yourself by running ` or by manually update the package and create a PR with that. r-ryantm goes through all packages so it can sometimes take a few days until the update PR is created. Also nix-update is very lightweight with minimal dependencies, so there is not really a reason to not use it. It also does not require any kind of token or authentication.
Bottles the version released after the one currently present in nixpkgs, was released on June 13. Over one month has passed, so something about the auto-updater isn't working.
The latest r-ryantm log is here . Not sure why that is not working like it should.
I guess a update script is needed for this case :disappointed: Since the package is using , it HAS a fallback update script , so nixpkgs-update is no longer trying to figure out the latest version itself but just run the script.


However seems like cannot handle the version , so it will fail at You may just try Repology gets software latest version from various Linux distributions that ships this app, so since AUR and OpenMandriva have 2022.6.14 (no suffix) the latest version is 2022.6.14. Looks like there is also an related report in Note that nixpkgs-update does not really tries to bump package in this way because it has an fallback update script.


Steps to reproduce the behavior: See Broke 3 days ago, (also broken for python-3.10 and x86_64-darwin, probably here )
Same issue when trying to run .


Describe the bug fails to build when attempting to cross-compile to aarch64 on : To Reproduce Expected behavior builds without error. Metadata nixpkgs Maintainer information:
I marked this as stale due to inactivity. →
Not stale - this issue still reproduces on current nixos-unstable ()


This is . Trying to build bcachefs-tools` for an aarch64-linux from x86_64-linux produces: I think comes from binutils. Adding binutils to nativeBuildInputs wasn't enough to fix it.
It's using a non-prefixed version of , it should instead be using
And after that we need to pass something like to cargo (or maybe directly to rustc?) somewhere. And we're spoiled for choice here: from in the Makefile to and env variables to maybe even .
I was able to fix this partially with this diff: That fixed the issue but seems like our libraries are incompatible? <details</details
Something has to be substituted in the source because ar is hardcoded
Applying that patch and adding The build now fails at
command encounters an error? Weird.
The built file is in instead of


is not included in the version of xivlauncher in nixpkgs, meaning that xivlauncher is currently broken. The update will need a backport to 22.05. <!-- 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: xivlauncher <!-- 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: xlcore 1.0.0.9 (upstream release 6.2.33, which I think is probably a more useful version number to use, since xlcore remains at 1.0.0.9 in the most recent release) desired version: 6.2.44 <!-- 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.


When adding a local directory to spotify client, it always fails due to missing gsettings schema(s) and spotify crashes. This issue is the same as the one from 2021 Works as expected on arch based distros indicating that this an issue with nixpkgs Steps to reproduce the behavior: spotify Settings on Show Local Files ADD A SOURCE button Open a file chooser to select which directory to be . <!-- 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 can't actually reproduce the issue, but I do see some inherent packaging issues that I attempted to address. Can you test the linked PR?
I also cannot reproduce the issue. However, I have never actually had local files appear after I have their directories (without crashing).
Yes your PR solves the issue!!! Thanks a lot for the fast reply :) I would really like to learn more about packaging programs for nixpkgs so I can contribute more myself. Do you have any recommendations on how to learn the different options for mkDerivation, the different phases, wrapping programs and libraries, etc.? I feel like the documentation is basically non-existend. If anything comes to mind (including workshops, etc.) feel free to just send me an email (this issue is probably the wrong place to discuss this)


Project description To interact with Google Drive via the command line, there are and , both no longer maintained and now in my experience unable to authenticate with Google. still works, but it only targets public files and folders. There is a spiritual successor / fork of gdrive (2): gdrive 3 Metadata homepage URL: source URL: license: mit platforms: unix


Project description <!-- Describe the project a little: --An UI for search and replace on neovim It has replaced for me Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


fails build as Should we force package to , or maybe remove it? No maintainer. Maintainer information:
And stating the obvious it broke with commit


Project description mgmt: next generation config management! Metadata homepage URL: source URL: license: GNU3 platforms: unix, linux, darwin
After fixing up the mgmt make scripts , from !/bin/bash to !/usr/bin/env bash trying to build from 'nix-shell -p go git' git clone cd mgmt make path make deps make Building: mgmt, os/arch: linux-amd64, version: 0.0.21-90-g5c6a66e-dirty. go build runtime/cgo: copying /run/user/1000/go-build892927552/b057/pkg.a: open /nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go/pkg/linuxamd64/runtime/cgo.a: read-only file system make: * [Makefile:175: build/mgmt-linux-amd64] Error 1 go env GO111MODULE="" GOARCH="amd64" GOBIN="/home/demo/gopath/bin/" GOCACHE="" GOENV="" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/demo/gopath/" GOPRIVATE="" GOPROXY=",direct" GOROOT="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.8/share/go" GOSUMDB="" GOTMPDIR="" GOTOOLDIR="/nix/store/y2nrzzz2yz7k36xvwr7bbfx76cb8jg16-go-1.14.


8/share/go/pkg/tool/linuxamd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGOENABLED="1" GOMOD="" CGOCFLAGS="-g -O2" CGOCPPFLAGS="" CGOCXXFLAGS="-g -O2" CGOFFLAGS="-g -O2" CGOLDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/run/user/1000/go-build275716735=/tmp/go-build -gno-record-gcc-switches"
mgmt now compiles under a I'm going to need a little bit of help to turn this into a nix package, as i'm not too sure how to handle it , as there are buildgopackage, buildgomodule , vgo2nix etc etc . Any pointers welcomed. to avoid I had to remove the -i from the go build this seems to be related to this NixOS/nixpkgs golang/go to run
I marked this as stale due to inactivity. →


Project description <!-- Describe the project a little: --Tools to manipulate pdf files. Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , ... platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'll see what I can do, should be good practice working with Gradle apps
Thank you Tom, much appreciated, best of luck.
By the way, I have pretty much succeeded in packaging it, and it seemed to run fine. Just forgot about it a little. The only issue with the package currently is that jar files are created non-deterministically by default (timestamps are not set to a fixed time). After using the fixup hook made for this situation (unzip and rezip the jar file) springboot doesn't recognise its files anymore, which is really weird. So it stayed non-deterministic. So I have two options: A) use the non-deterministic package or B) use the prebuilt jar from GitHub. The latter one is much less complex to work with.
See if this helps you.. or this discussion from the top (concerning java apps)...
Thanks for the pointers, though the second thing linked is my own post :) I finally managed to figure out how to fix the jar timestamps, so I'll open a PR adding the package
Thank you for your help . Much appreciated.. sorry for the delay. had a rough week last and it spilled into this one. Looking forward to using stirling-pdf on nixos.


When trying to install firefox with , I get the following error: It seems is already gone on : Considering it doesn't work on 18.03 anyway, could we cherry-pick the commit to 18.03 to disable the VLC functionality? system: host os: multi-user?: sandbox: version: channels(sepp): channels(root): nixpkgs:
For whatever reason, on master I seem to be getting this error even without this (or other firefox configurations). So the issue could be broader than this. I suppose for you it worked after removing this option then?
This is now caused by another source on ; it should be fixed by (in branch, half of binaries built ATM).
The other issue is also fixed on master since .


Wanted to install and start sweethomed.application. the build worked without problems but when i started it, it didnt started. Steps to reproduce the behavior: sweethome3d.application via configuration file to start it Starting the Application stucks at the start screen ! Add any other context about the problem here. At the moment its installed in my user context. When i try to start it as my user over the terminal i get no errors. When i start it with "sudo sweethome3d" I get the following error, and it also dont start, also start at starting screen and vanishing from the task bar: I think these happens because its not installed as user, but propably it helps to find the issue.
Starting random applications as root seems like an unwise idea.
Apologies, I misread the error, this appears to be a separate issue
Just to confirm, which GPU do you use?
I've got the same issue, and none of the solutions given in appear to work. On my side says my GPU is . EDIT: I should mention SH3D 7.02 works fine on my setup Mmh, I just tried with , and things work just fine (even though I'm on NixOS + tells me OpenGL is happy)...
Same problem here, on NIXOS unstable. Stuck on the starting blue window. Had to install it with flatpak in the mean time... Any idea?
sorry for delay i dont get informations from messages in last time from github... really annoying... I have an Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]
Same here, also on Intel hardware.
Based on the NixGL idea, applying the following patch works to update to the latest version and fix the driver issue on Intel. But this does not seem like the best way to go about it; I can't find a single other package messing with , and it seems more like a debugging tool than something that should be in a package.
I forgot to mention, to avoid getting terrible performance (< 1 fps), I also had to set Not sure if it's needed for others. Maybe related to my using Wayland/Sway. I also have to use to get the window displayed properly, but that's a common issue for most Java apps and tiling windowing managers.
I also ran into this issue with a Nvidia card.


For me, was needed (with patch). I also needed . and didn't seem needed (or give noticable changes).


plasmatube can't play the video (black screen). probably need to add a dependency or similar. Steps to reproduce the behavior: plasmatube can play videos from youtube. ! system: host os: multi-user?: sandbox: version: channels(hervyqa): channels(root): nixpkgs:
solved, need install . !


Describe the bug When the filesystem scrubbing service configured via is running, the system cannot shutdown until the scrubbing is completed. To Reproduce Steps to reproduce the behavior: the autoscrub server on some Btrfs file system, e.g. by the resulting service, e.g. the system: that the system only shuts down once the scrub has finished Expected behavior The scrub should be aborted properly when the system needs to shut down. Potential solution By default, running services are stopped by a SIGTERM, but apparently the btrfs scrubbing doesn't react to that. We need to introduce a custom into the service definition. This approach still needs to tested properly though. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(user): nixpkgs: Maintainer information:
This will also need a fires of a iirc, and then exit immediately, so there is nothing to as the oneshot exists immediately and then gets removed from systemd memory. So to get this to work we need:
Is really needed with ? Also cancel does not accept .
Oh my manpage-in-my-head read as block device .. not as blocking.... Scrub what I said! should be enough here I think. Also I think this is a great thing to add a NixOS VM test for
While I'd love to have some tests for this, these may not be so easy: We need a filesystem large enough that the scrubbing doesn't immediately finish before the shutdown is initiated.
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 .
Fixed by


This weekend I tried these games, all deadlocked in the menu or character selection. Nyheim Oh...Sir! The Insult Simulator Reigns Unturned (free to play) You don't have to be worried to waste money in case you want to test a game. I have had no problem when requesting refunds, just go to I have played these games and found no issues with them: Dota 2 Counter-Strike TIS-100 World of goo Faster Than Light You Must Build a Boat Risk of Rain System: (NixOS: , Ubuntu/Fedora: , ...) 03pre99759. (Gorilla) Nix version: (run ) nix-env (Nix) 1.11.6 Nixpkgs version: (run ) "17.03pre99759." Integrated graphics card, 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
This is normal with steam on nixos unfortunately. There are many steam games that don't work for various reasons, unfortunately many linux steam game developers only make sure their games run on ubuntu and don't really care about relying only on dependencies from the steam runtime. Some games don't play nice with certain graphics cards or drivers as well. If you want to get a particular game working (I can list 150 games that work under nixos with nvidia card and drivers at least) then you'll need to do some work, or at least post any relevant logs from the game/steam so people can actually help you solve the problem. That is assuming that they own the game. :)
There's a slowly-growing list of extra dependencies in the Steam package. If you can figure out what's missing, you can add it there; e.g. as in
I don't have enough motivation to actually buy games for the sole purpose of fixing them and then refunding, sorry. Nevertheless, I'm happy to help if you can post logs and/or s -- those two are the most helpful for determining FHS-related problems.


hooks with work by . This fails because is a plain binary that doesn’t have in its environment. Steps to reproduce the behavior:
A workaround is to use the binary from instead.
It seems the above fix is insufficient. While works correctly, the hook installed into doesn't have the Python environment with the pygrep package. tested on:
Still same problem...
If you pull in the above mentioned into your environment, it should work. For best results, I recommend putting it into your (& use direnv) or systemPackages.
Potential fix which doesn't require changing the python provided in the nix shell:


Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: tdmupdater tdm Expected behavior tdm starts. Actual behaviour tdm starts with a black error and has stderr errors such as: Additional context It looks like the problem might be that and the assets downloaded via tdmupdater are different versions: Workaround (Steam isn't actually used for this. This is just a lazy way to run FHS programs.) Notify maintainers Metadata** Maintainer information:
There's a version update in master. I don't know when it'll land in unstable (maybe it already did?) or stable.
Is it possible to have NixOS stable not break when upstream changes? Either: (a) NixOS stable should include the TDM assets (in which case tdm_update is not needed) (b) becomes solely a shim to grab assets from the TDM assets, so it doesn't matter which version of is used.
require patching the path to ELF interpreter, along with worrying about lib dependencies. complicated: TDM players are accustomed to dowloading extra missions, which requires a writable directory to hold the data. Do you have a proposal how to do this securely? Hardlinking the default install to /home would break if /home is on a different FS. Suid wrappers smell. World-writable bits in /nix smell too.
Surely the engine supports multiple asset directories, so we can load the assets from the nix store in addition to whatever was installed manually into a local directory.
The comments on suggest The Dark Mod stores save games in its installation directory. tracks this issue.
I have another issue that seem to be related. Running tdm via the ` work however. The relevent line are: When it doesn't work and with the second option
I poked around - and I don't have any ideas why OpenAL might not be finding hardware. Right now, it seems that the best course of action is to remove TDM from repos (to avoid creating false expectations), and run it with steam-run. and do you agree?


Project description Scalene is a high-performance CPU, GPU and memory profiler for Python that does a number of things that other Python profilers do not and cannot do. It runs orders of magnitude faster than many other profilers while delivering far more detailed information. It is also incorporates AI-powered optimization suggestions. Metadata homepage URL: source URL: license: Apache 2 platforms: unix, linux, darwin, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


The build is failing on master; it has been reproduced at . An example of the failure is below: There is a new release () which also doesn't pass, so I didn't send the PR as it'd fail on CI. Steps to reproduce the behavior:
Those aren't the failing tests (BROKEN means they are known to fail). These are the real failures: Looks like a broken test directory setup in the build environment.
fixed in the next point release I think
prior work


Project description Wavefront is VMWare product and, per their website, is an "Enterprise-grade cloud monitoring and analytics at over 4 million data points per second." The service can be provisioned via Terraform -- there's an OS Terraform provider available here: It should be included amongst the set of existing Terraform providers that already contains. Metadata homepage URL: source URL: license: apl2 platforms: linux


Tailscale package is not using the unless is set. Steps to reproduce the behavior: tailscale and set a flag ==no flags are used Flags are used If applicable, add screenshots to help explain your problem. Code reference: extraUpFlags is only used inside the if of auth key not being null check. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This caught me out too - could just be as simple as a warning/error when setting without ?
I don’t think that is adequate as you can run tail scale as server just fine without argument. An is only valid for up to 90 days.
Sure, but it would be a good start to alert users to the current behavior.
I was managing personal nixpkgs only because of this issue... (simply patching package doesn't seem to work for modules) Created PR for this. Hope someone can review this.


Steps to reproduce the behavior: status: status: status: This was discovered via pr <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems like some tests have began to fail. When testing, the traceback shows the following tests fail because they don't initialize the module correctly (with ). - These tests don't undermine the functionality of when building from source, so I'm inclined to believe that the culprit is itself. Looking further, throws various deprecation warnings when the tests run. I fear that the more NixOS receives updates to , the more the tests will become more deprecated. It's unclear how NixOS feels about packages and their tests (particularly whether it's necessary for a maintainer to maintain package tests), but the current workaround is to disable these tests. Adding the tests to the field produces the result package, and continues to work as normal. I'd like some input on how to approach as this does feel pretty hacky.
We could override pytest back to a previous working version. I looked to the upstream package and it hasn't been updated in a year, to which was just a readme update.
Wouldn't this affect newer packages (assuming they use as a unit test framework) who utilize newer features of ? Though hacky, the solution I've suggested gets the job done. As mention previously, the failure of the tests don't influence 's functionality.
Disabling problematic tests is done a lot across nixpkgs. Since we know its still working when they are disabled it should be fine.


Project description A CLI program that will let you save and apply your Linux customizations with just one command! It officially supports KDE Plasma but it can be used on all other desktop environments too! Metadata homepage URL: source URL: license: gpl3 platforms: linux


<!-- 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: <!-- 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.
I started preparing the update in . Cc:


There is a license violation in the package. The package contains the code for under the old MAME license which is non-commercial and incompatible with the GPL code in the rest of the program. I tried to notify upstream, but that didn't seem to go well...
Hello! It seems that upstream actually an option to disable in version of . , from my testing, gives me an error when I try to run it. You can find more info in this . So, i think merging the pull request linked to this issue is the best option right now.


Xed Text Editor from Linux Mint Text editor from the Linux Mint distribution xed text editor homepage URL: source URL: license: gpl2 platforms: linux
needs an update of a dependency to package newest version 2.8.4


The package 18 on master failed to build. Steps to reproduce the behavior: build github:nixos/nixpkgs#clevis ! Full build log:


The repo URL is missing for: To fix it, you can fork (I forked it for preservation but neither of us made changes: ) then change the GitHub username in the nix file to yours. I don't have NixOS or have any way to test this. I ran into your nix file while trying to find the maintainer: I asked whether the repo has moved because it is deleted from GitHub. I contacted him via 's contact form and I'm awaiting a response (I didn't try an e-mail address found here yet: ).
Recently I have read somewhere that the author was absent from some social media, and that for personal reasons he has removed his account on github, and that this software is still available on launchpad. Github was just a second home for it. But I am not finding this info anymore.
Ok, the author responded to me via e-mail that the launchpad URL is correct, but that he isn't maintaining it. He says he's more likely to rewrite it in Rust rather than update it. The nix file can be corrected to use launchpad, but in light of that information, using one of the GitHub forks or forking one of them yourself and turning on the "Issues" feature is probably the best route to a future for it, even to a minimal extent of getting bugfixes.
I am changing the upstream source to the launchpad repository, as it is the most correct. I am also watching the two forks on github, so that I will be notified of new actions on them.


Package name: Apx Latest released version: 1.8.2 <!-- Search your package here: --- Current version on the unstable channel: 0-1 Current version on the stable/release channel: N/A <!-- 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.


I just filed a to update our version of CEF to fix a . The previous version was released on 2019-07-27— that's almost 2 years! For a piece of software that's functionally a web browser, we certainly shouldn't be using an out-of-date version: web browsers have a massive attack surface and it's very important to keep them updated at all times. I don't have the time to work on this right at the moment, but it shouldn't be too difficult. There's a containing metadata for every CEF release. All that should be necessary is to grab the latest stable version for the right platform. While we're at it, we could also consider building for i686 and AArch64. Tagging the maintainer
IDK how it works, but it sounds like a job for the bot ().


HTTP Toolkit is an open-source tool for debugging, testing and building with HTTP(S) on Windows, Linux & Mac. Metadata homepage URL: source URL: license: AGPL v3.0 platforms: linux, darwin
Sorry, wasn't able to get it working. The httptoolkit-server is the difficult part. I tried building from source, however one of the dependencies tries to npm install more stuff in prebuild, so it wasn't building properly. I tried packaging the prebuilt binary but it's trying to do some auto updating and also package node with itself. I could have patched this when building from source, however the prebuilt one is minified & obfuscated so I couldn't do that.
Have you a branch to continue the work ?
+1
I've started a small bounty of 20$ on this: It's not much but it would be great to have this tool on nix!
I made another attempt at packaging this and I'm pretty close to getting httptoolkit-server to compile from source. This should help with patching out stuff, since we can do it before it gets obfuscated.
if anyone needs to run this on nix the appimage provided by HttpToolkit works pretty well on nix with no extra dependencies. See and then Would still be great to have this as a nix package though.
Hey thanks for adding this! You can claim the gitpay bounty here: (I've tried to find your email to invite you but didn't have much luck) or email me at
Sent you an email,


<!-- 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: mednafen <!-- 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.26.1 (dated November 10, 2020) desired version: 1.29.0 (dated January 19, 2022) <!-- 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.


Steps to reproduce the behavior: dvc with aws integration I am running nixos on the unstable branch. Please run and paste the result. Probably fsspec needs an update to 2022.8.2
Will be fixed with .
Oh sorry for the noise, did not search the PRs.


Steps to reproduce the behaviour: PyInstaller on Darwin It fails to build at gcc as gcc is not avlible on macOS CC <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Is it possible that you can make gcc only in linux but clang if pyinstaller uses clang for darwin to use that?
I got it working I am willing to contribute a fix to this.
I will need to some how package since requires it for macos systems.
But first of all since gcc is required on linux is there a possible if linux include gcc instead of clang.
Based on , it seems like and the stuff is only required on linux. Maybe we could just throw in a here? Do you know if more needed to be done to fix the darwin build? Feel free to open a PR if you'd like.
You need which I am looking to make a package for and I think I still have to test if you need . I am looking to make a pr in a couple of days to fix both pyinstaller and package
I think gcc can be replace with clang which is compatible with both linux and darwin.
Macholib is now in a pr:
Now I am looking to fix pyinstaller for darwin.


Project description A highly automated and intuitive digital audio workstation. Metadata homepage URL: source URL: license: AGPLv3+ platforms: linux
This is a stub of a derivative for ZRythm:
Did you see It's for an older version, and I haven't compared it to your gist, but maybe you would like to do that?
I marked this as stale due to inactivity. →
Still relevant.


The [monado] package doesn't install the udev rules generated by the [xr-hardware util] from the Monado project. Install the package and check the lack of udev rules in It was expected for the udev rules to be installted with the package. The udev rules are needed as some hmd's have some strange and specific permissions. Maybe instead of adding this to the package, monado could turn into an option like . <!-- 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]: [monado]: [xr-hardware util]:
Trying packaging the udev rules similar to how . [brscan4]:
I was working on a Monado NixOS module. Perhaps I can deal with udev rules there. See


Describe the bug cmake-gui doesn't launch it shows an error like:- 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 Please run and paste the result. Maintainer information:


Package name: digikam Latest released version: 8.2.0 Current version on the unstable channel: 8.1.0 Current version on the stable/release channel: 8.1.0 Notify maintainers Changelog: Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Not valid cryptography in python3 ... Steps to reproduce the behavior: switch "Screenshot" Install yubikey-manager ;) Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- as cryptography maintainer Please run and paste the result.


I set up a brand new NixOS system with nothing but . After switching to the new configuration, I ran and was surprised to find in there in a and state. I poked around and it turns out that our module refers to in its section: It sort of makes sense, because presumably you want your webserver to spin up after your database, but it feels kinda icky to give completely unrelated (in principle) services dependencies on one another, especially when some of them might not even be on your system. I suppose we could make that entry conditional on , but I'm not sure what the pros and cons of that are.
Yes, I'd think it would better be conditional. Units should get reloaded on system switch IIRC, before starting new services, so I see no danger in that.
I think, this link should be broken unconditionally. In my scenario apache-httpd is used solely for SVN web interface, and while I have running Postgresql instance, they are orthogonal (postgresql is acompanied by tomcat container/nginx pair)
Perhaps, yeah. It also appears to depend on , which I think is a nixops-ism.


Describe the bug Building neovim doesn't work anymore. To Reproduce Checkout master branch, commit (latest as of now), then build: Expected behavior Building neovim should succeed.
The failing code is (...-stdenv-linux/setup: line 320):
Having the same issue when updating my system.
Ping I think this has something to do with the recent stdenv changes. Do you know how to fix it?
This is from which breaks this manual sourcing of setup hooks I say this is a good thing! We should make those proper dependencies. I will fix shortly.
I have a similar issue in stdenv-linux/setup /nix/store/fiaj00zrmb7dynd2q9xmcrh5rn0mjwj0-stdenv-linux/setup: line 97: $'r': command not found builder for '/nix/store/frqmqjyg649bkqivqhzq041fxbfvsikw-cockpit-' failed with exit code 127
Thanks!


cannot process svg files despite the documentation advertising it can. Steps to reproduce the behavior: SVG should be supported Introduced in Build logs: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: