This is especially important for Home Assistant, which and fails to build without it. 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.
Can you tell me what nixpkgs version you are using? On master home-assistant builds just fine, with bcrypt at 4.0.0, because we do in fact relax its constraints a bit. Added variables. nix-replhome- «derivation /nix/store/044cr7v736265qjiq2b3vc7r7hxbaqfd-python3.10-bcrypt-»
I'm on . More build logs:
Upon further inspection, the file does appear to be patched correctly, but there are still in and . Maybe those have something to do with it?
My bad, I just realised I was overriding without including the original
That explains it.


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.


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.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I opened a PR here: Thanks in advance for reviewing :-)


The  package (which I and maintain) has a that is rendering wrong at It seems that I used the wrong markup language. I'd like to ask: what is the markup language that we're supposed to use in s? I've been unable to find an answer to this in the documentation, and unable to find a working example in some package's file, even though IIRC I've come across some description in search results that correctly rendered some quoted code with extra styling. When I first wrote my package's description, it was 4 months ago with NixOS 21.05, and I'd somehow thought that DocBook was the correct language to use. Looking at other packages' descriptions, I see some other attempts to use markup (or Markdown), which is maybe what influenced me, but now I see that these are also rendering wrong. My longer more-structured description looks especially bad, so it should be fixed.
As far as is just plain text.


A config file is read-only, which causes the program to fail entirely. The leo text editor should run when invoked. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Not fixed:
this has been fixed on the master branch however has not been backported. I'll create a PR to backport this, in the meantime if using flakes you can update nixpkgs to follow master or nixpkgs-unstable otherwise you can update your channel to follow unstable. works fine for me. EDIT:
Are you sure? Are you sure?
!
works on my machine, which makes it extra strange that installing it locally with a flake that is pinned to does not.


Steps to reproduce the behavior: ouch on x86_64 darwin Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


<!-- 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: mpv <!-- 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: 0.33.1 desired version: 0.34.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.


They're trying to be smart: We should probably patch that check out, but maybe people with actual Java experience will have better ideas.
We need to patch that. Neither do we want to provide cygpath nor can we wslpath because that would most likely try to escape the sandbox.
The thing here is that they see WSL and automatically assume we're cross-compiling to a Windows target, which we're not. We can patch this out, or maybe we can force it to not cross-compile somehow, or maybe we can make lie.
I would recommend to just patch that out.


I'm trying to use it on aarch64 and this is failing: [6/257] Building CXX object FAILED: /nix/store/fsn9mccnjinl212ypa3rx8b8647s9klh-gcc-wrapper-12.2.0/bin/g++ -DCEFUSESANDBOX -DNDEBUG -DWRAPPINGCEFSHARED -DFILEOFFSETBITS=64 -DSTDCCONSTANTMACROS -DSTDCFORMATMACROS -I/build/source/thirdparty/cef/cefbinary104.4.26+g4180781+chromium-104.0.5112.102linux64minimal -O3 -DNDEBUG -fno-strict-aliasing -fPIC -fstack-protector -funwind-tables -fvisibility=hidden --param=ssp-buffer-size=4 -pipe -pthread -Wall -Werror -Wno-missing-field-initializers -Wno-unused-parameter -Wno-error=comment -Wno-comment -Wno-deprecated-declarations -m64 -march=x86-64 -fno-exceptions -fno-rtti -fno-threadsafe-statics -fvisibility-inlines-hidden -std=c++14 -Wsign-compare -Wno-undefined-var-template -Wno-literal-suffix -Wno-narrowing -Wno-attributes -O2 -fdata-sections -ffunction-sections -fno-ident -UFORTIFYSOURCE -DFORTIFYSOURCE=2 -MD -MT -MF -o -c /build/source/thirdparty/cef/cefbinary104.4.26+g4180781+chromium- g++: error: unrecognized command-line option '-m64' ninja: build stopped: subcommand failed. error: builder for '/nix/store/a7r53z6050vvhlmwnxac6c6kp41gcz2g-jcef-jetbrains-' failed with exit code 1; last 10 log lines: For full logs, run 'nix log /nix/store/a7r53z6050vvhlmwnxac6c6kp41gcz2g-jcef-jetbrains-'.


error: 1 dependencies of derivation '/nix/store/9mds0h6675lnh8hgam63xycvv8lrb01v-jetbrains-jdk-jcef-17.0.6-' failed to build
WSL2 on aarch64? Also, this error is for Chromium.
Sorry, never mind. I'm having an issue with , that has a dependency on CEF. I posted in an incorrect place. I opened a separate ticket. Please ignore.


Project description A command line editor for HCL Metadata homepage URL: source URL: license: mit platforms: darwinarm64, linuxarm64, windows_arm64 Release page: Copied install info from readme: If you are macOS user: Download the latest compiled binaries and put it anywhere in your executable path. If you have Go 1.20+ development environment:


The package is failing to build Steps to reproduce the behavior: The package to build successfully without errors
I'm sorry, I haven't used in years - but also nothing with that package has changed in some while. I'd assume an upstream problem?
I don't use but took a look out of curiosity. It was an upstream problem that is fixed by a few commits after the latest 2.4.0 release. There hasn't been a new release since then. Is the best thing to do here pull down that commit as an isolated patch or to bump the revision that's pulled down to that (untagged) revision?
Can we use in the meantime?


Steps to reproduce the behavior: python3Packages.rapidfuzz Introduced in . Please run and paste the result.
It appears that cmake selects an incorrect linker. I am currently unsure what's the reason for this. Following I think I might need to set: I have zero experience with nix os + no access to a mac. Is there any way to patch in the build system here to check whether this solves the issue?


I get this error when the packages i build contain any musl one. Blocking me from reviewing PRs. Full error: Issue for a more helpful error message: Steps to reproduce the behavior: No error. I think the solution would be to disable musl libc on i686-linux until it actually works. So Nix or nixpkgs-review don't even try to build it. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Collecting information: this looks fine maybe here needs to be a check for 64-bit


When I try to open the warp-terminal on wayland it crashes without opening any window and get the following logs: Steps to reproduce the behavior: to open warp-terminal happens It should open the warp-terminal window and prompt. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Might be helpful:
Fixed in , I tried running () on KDE Wayland and everything works as expected
A warp-terminal dev has stated that wayland support is explicitly still experimental and off by default for this reason. Please do not open issues concerning configurations that are explicitly unsupported by upstream.
Sorry, I didn't know it was explicitly unsupported by the upstream since it was working before just fine on Wayland. Thanks a lot anyway!


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.
You don't need to open an issue if you're going to make a PR right after.
Apologies, my bad. I was not aware :(. I am only 1 day & 1 PR old here.


A clear and concise description of what the bug is. Steps to reproduce the behavior: created with expected behavior from This might be due to vhs being outdated in nixpkgs. Please run and paste the result.
Nixpkgs has since been updated to the latest version (v0.2.0), and the error still occurs on the latest Nixpkgs commit ()
Any suggestions on a fix?
I believe the fix might be to include as a dependency and ensure that looks for the binary in the same place nix installs it (i.e. it is located in the as chromium):
The PR for this breaks vhs on darwin, since chromium isn't supported on that platform
Thanks for filing a new issue


It would be nice if the package included shell completions for bash, zsh, fish. Steps to reproduce the behavior: (In fish): pipx-specific shell completions should show. One problem specific to is that the instructions you get with do not work unless you know to install the binary first (e.g. ). I hope that mimicking would work (though I'd also like completions to be included). I might be able to try that myself at some point, but I'm not very familiar with testing that a patch to works. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


the strict commit history guidelines require frequent use of , a command which may be unfamiliar to those that are used to projects with more lenient commit guidelines. find or write a high-quality guide to and make it available in <!-- make sure this issue is not redundant or obsolete --- [x] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [x] checked [open documentation issues] for possible duplicates [x] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


So I today I spawned a machine with and satisfyingly the directory was generated with all of the certificates etc that taskwarrior needs, including the clients' certificates. I noticed that the users' keys located at are owned by root with read only permissions for the root user alone. No matter what are and . I'd like to enable the group read those client keys, as well as the file so that I can configure a client easily. Thankfully the group can read the file, but not the client keys. The manual indeed explains that the command: Could be used to get those keys, but I'd like to use syncthing for that to automate the process even further. I got a bit lost while reading the . Specifically, I'm not sure why does always works in the following umask: I mean, ~why not~ - a solution is suggested in . A word of comment will be appreciated. cc .


hangs when given a derivation because of infinite recursion either error or treat it as a string, which all other generators seem to do <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Maintainer information:
is there a context where a derivation would even be a valid input for this function? If not perhaps a simple fix would be to test for a derivation as input and simply throw a warning instead of continuing computation.
it shouldn't be possible to use derivation as a attrset for this function, but store paths could be useful which is similar to 's behavior
So this worked without error: I was able to reproduce the issue by just passing your example input above though, and in looks like nesting the derivation deeper also still causes the error. I guess we could map over the input at the start of the function and convert any unconverted derivations to strings before moving on. That should allow us to declare store paths and avoid this issue. Side note: you shouldn't have to restart your system to recover from the error condition; worked for me
I forgot SIGKILL existed. I removed the warning in the description
I have run into a very strange issue. I thought that the following patch should be all that is required to fix this: however even though I confirmed in repl that the conditional evaluates to false when passed `"${hello}", the codepath guarded by the conditional still seems to run anyway and fails with the following error: to add to the confusion, if I push the value one level deeper then it works fine:
i don't think ini support values at top level, or maybe its just the ini generator?
ah okay, then I guess my change is completely ineffective. I'll keep iterating :laughing:


Helm defaults to a kubeVersion 1.20.0, which is 3 years old. Steps to reproduce the behavior: Would expect that helm defaults to a kubeVersion that is apart of the supported Kubernetes compatibility. helm 3.12 should support something similar to kubeVersion 1.25 accorsing to their version skew, The last version of helm to officially support 1.20 was 5 minor version ago Unclear where this default version is being defined. Downloading the corresponding binary directly from (example: ) does not encounter this issue <!-- 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]:
Great timing! I just ran into this issue not to long ago but I'm unsure how to resolve it. (On mobile so I'm going from memory) there is a hard coded version in the helm or something like that, that can be overridden at build time. Presumably the helm team does override it. We can of course override it as well but I'm unsure how we can keep it up to date. It would be a 1 line patch to fix it for now but my question is, is there an automated way to keep it at the same version as whatever the helm team uses
normally helm takes the k8s version from the go k8s client lib and increments the first part by 1 to arrive at the k8s version. On my current dev system the output is as following (debian sid) In go you can directly set via as the Makefile does, but it's not always clear that those things can just be overridden that easily. i'd prepare a patch but i've no idea on how to add some script execution into to fetch the variables :/
I am not sure how to add in script execution either. As a low tech eventual solution, opened a pull request to resolve the issue upstream.


Project description A pure rust implemented turn server. <!-- Describe the project a little: --Metadata homepage URL: source URL: license: gpl-3.0 platforms: linux, windows Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


fetch-bower produces truncated nix-store entry when run under nix-build: Looking into the retrieved jquery in the nix store you can see jquery is actually missing: It works fine when trying to manually run it as a regular user: bower- generated by : run nix-build System: (16.09beta172. (Flounder)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: (16.09beta172.)
ping
Sorry for the delay I will test and merge today.
Hello thanks for your detailed report. I am getting slightly different results to you, so more investigation will be necessary. In my environment (NixOS 16.09 channel), there was no hash mismatch. Possibly something caused git to fail to download the jquery package. If it silently fails producing an incorrect result, then that is a bug in bower2nix which could be reported at
I am not sure this due to bower2nix. Fetch-bower is calling git and should handle the error's accordingly, no?
It consistently fails for me both on the latest unstable and 16.09 channels. Can you try updating your channels? My suspect was commit but I wasn't able to revert it cleanly to try it out.
By , I also mean . I have rolled the two programs into one repo. You are definitely right, is calling (indirectly, through the API), and should handle the error. I'm an avid subscriber to 16.09 and especially nixos-unstable, so have tested on those. Obviously it would be easier to fix the error handling if I can make fail myself. Do you have any further info about your setup which might be relevant? E.g. any proxy settings required for git to work. Can I also confirm that you are running before retrying ?
I don't have any proxy settings. Is it possible GitHub is rate limiting requests from bower? I found this thread interesting And yes I am running nix-store --delete before trying nix-build.
Hi are there any additional details I can provide? I am not that familiar with typescript or javascript, but I could try to narrow the issue down with some help.
How to reproduce: Expected output: bower package info json.


Actual output: nothing, not even an error message.
This problem is back. I can reproduce it by following the steps outlined in the top message. (latest nixpkgs-unstable) It did work for me a while ago though, so it looks like a regression. Did some digging around but I cannot figure it out. cc
Good catch, I think I've seen the same issue as well, but didn't bother (lack of time). Could be a different cause, but we have to start somewhere :)
Running produces correct result while -ing the following produces an output without jquery (just meta data)
Figured it out. Git doesn't see SSL certificates. I made it run with this expression I'll try to open a PR to fix this in nixpkgs. I'll also try to open a PR to bower2nix because there is a bug in it - missing SSL cert should not result in exit code 0.


Project description <!-- Describe the project a little: --This is a electron-based app client for Pritunl server Metadata homepage URL: source URL: license: Non-Commercial platforms: linux
Pending review in


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.
Hi Opened PR for this.


Package name: upterm Latest released version: 0.12.0 <!-- Search your package here: --- Current version on the unstable channel: 0.10.0 Current version on the stable/release channel: 0.10.0 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- tried
Bumping to 0.12
Seems this need the vendor path now.


On nixos-unstable libglvnd (I think) has been failing to build since about a week ago. Build log: Update to the latest nixos-unstable channel Run with nvidia in
Related?
Actually it looks like this PR fixes this issue. Though nix channel is not yet updated.
Confirmed. Adding the following override fixed it for me:


Every new firefox update/rebuild generates its own (new) profile. This is annoying, as we rebuild firefox whenever any of its dependencies changes. See: Start with the profile manager or with a custom profile
Should not it be just one profile per branch – one for stable, one for beta, one for nightly? Updating should not change the branch.
I thought that too, but at least for me it created 4 profiles already - could be, that the FF beta is not smart enough (yet). Anyway, now it's documented, so people hopefully won't get as confused as I've been when/if they reproduce this.
Can repro as well. Unfortunate!
Not explicit above, but the workaround is: you see "this firefox uses a fresh profile"... quit firefox profile manager with an older profile and "use as default profile" as normal until the next update
Related issue: and workaround:
Firefox 67 is now the stable release, when I upgraded unstable this morning I got hit with this issue, I'd guess a lot of other folks will shortly as well. Could the SNAP_NAME workaround be incorporated into the derivation until there is a fix from Mozilla? If there is a better fix out there then maybe that.
Just got made aware of the issues as well. I'd sway te SNAP_NAME workaround is okayish for now. I will try to get a patch made so that we do not need that in the future and have a proper kill-switch for that... Sorry for the troubles. I missed that during testing the latest release :'(
I opened a PR to add the workaround Will do the backport as soon as someone else can confirm that it works as expected.
Looks like the more general solution has been merged into Firefox and will be deployed with 68+. From The dedicated profiles feature is off when MOZLEGACY_PROFILES is set to 1 at environment level, while the downgrade protection is still enabled. Probably should coordinate a change to that environment variable name with the release of 68, though it looks like the SNAP version would work for a while after as well.
Can we set in the latest firefox now?
We could do that but that wouldn't work with former ESR / tor browser and probably a few other things. In the long run that probably makes sense.


I am not sure it is worth the extra code to use the newer (equivalent) option for newer versions and the old one for older versions. There are constantly users that want older firefox versions because of plugins, java, … so we shouldn't just remove them?!
this hasn't popped up in my daily usage for a while now - please comment/reopen if it's still an issue.


I tried to install Roundcube with an non-local PostgreSQL. The DB user password should be stored in a password file. I ran into problems with this setup: the password file is used in two locations: the Roundcube the systemd that initializes the roundcube database Unfortunately the neccessary file content differs for these two services: the roundcube the passwordfile should only contain the PASSWORD (even without a trailing newline) expects an entry like "hostname:port:database:username:password" () So one of these two services will fail. Setup Roundcube with remote PostgreSQL server and password file for DB user password. My solution for now would be, to add a line to the roundcube Please run and paste the result. Cheers, Andreas
Your solution sounds reasonable to me, if you replace with something that takes into account escaped . Would you mind opening a PR? Tag me on it, I'll review it. As you can see the remote db feature of the module has probably never been used except by you; if you want this use case to be better maintained consider contributing a nixos test exercising it.
Fixed by


Describe the bug Failed to build . To Reproduce in -rebuild switch Expected behavior Build successful. Screenshots  Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
New warnings/error are introduced with new GCC releases.
could you please give a try?
Yes, it works.


When typing something here: <img src="https://user-" width=50%The desktop crashes and you have to re-login (well it's Chinese in the screenshot but I hope you get the idea) <img src="https://user-" width=50%Steps to reproduce the behavior: budgie menu something crash No crash. See above. I don't see this issue before the GNOME 44 update. Probably another issue but I haven't go deep yet. I am on right now, it's nixos-unstable with pull request picked.
Backtrace points to <details</detailsLooks like there are changes on that touches after 10.7.1, I am testing that right now.
I gave the latest HEAD (i.e. ) a try and cannot reproduce the issue so probably some of the commits fixes the issue. I wonder if this can be reproduce by others and if some fixes can be backported before 23.05
Ohhh goooooood and now I am reading , let me make some noise there Edit:
And now I am on , which has glib 2.74 ( has 2.76). This is going to be weird because with G_SLICE=always-malloc I also cannot reproduce the crash (budgie-desktop 10.7.1), so probably not related to the slice allocator. Edit: and it's vala 0.56.4 on (no crash) and 0.56.6 on (crash)
Okay I guess I can basically confirm it's caused by vala update because I am now on and cannnot reproduce the crash, wow it's first time I know valac can really cause issues :seenoevil: Bisect is too painful for my slow laptop :upsidedownface:
Could you try compiling and running this Vala code on the broken version to see if it also crashes? It should do the same thing as the crashing Budgie code, just without crashing your desktop. If this ends up being a Vala issue, we need a minimal reproduction program to send.


Build and run with (assuming you put it in a file called ):
I am now on and my desktop crashes, so the current range is :upsidedownface: I am away from keyboard for the next few hours because it's midnight here but feel free to drop questions :upsidedownface: I built the program with vala 0.56.5, it exits normally with
Well, crap. I was hoping that would crash. Maybe this version when you get back? It's closer to the code in Budgie: Of those commits, the only one that really looks suspicious to me is at a glance.
I am still here (for now) :laughing: but this runs normally for me as well (hmmm can we really guarantee "if I can trigger the desktop crash, then using same vala same laptop same setup we can trigger a crash with some different program"?)


Even when vulkan is installed and working, opening chromium and going to chrome://gpu shows vulkan is disabled. Also chromium logs the following warning: Warning: Couldn't open Info: Couldn't load Vulkan at LoadVulkan () at Initialize () Running confirms that vulkan is installed properly and working. vulkan is installed and working with running chromium and go to chrome://gpu check if vulkan is enabled or disabled. vulakn is enabled in chrome://gpu Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(robert): channels(root): nixpkgs: Maintainer information:
Hey I think you meant to ping the chromium maintainers:
yes thank you!
Not sure if this is actionable, AFAIK Chromium's Vulkan support is still pretty experimental (depending on the platform). Did it even ever work before? Also: X11 or Wayland, which flags are you using for Chromium, and could you provide the full output? might be actionable but apparently it's only a warning so idk... You could use to figure out the complete path where Chromium expects . Relevant parts from the source code: ;l=43;drc= ;l=173;drc=;bpv=0;bpt=1 But since Dawn () is Google's WebGPU implementation this shouldn't even be relevant (yet). Anyway, I'm afraid you're on your own here as I don't have enough time to give it a proper look. (Potentially) also interesting/relevant: ,RAMandSwap,ChromiumWillEatItAll PS: I also finally submitted but that should only be relevant when using SwiftShader.
This issue affects also google-chrome.
seems to be relevant as it's ANGLE's Vulkan wrapper rather than the real libvulkan from the system. I only had a quick look through the source-code but it seems like we should definitely install it (but other Linux distributions don't seem to do it yet). Anyway, could you re-test this once is built by Hydra (maybe I can also give it a go during the weekend)? we already install for Google Chrome so it seems like there are some other issues as well. If you have time to debug/investigate that would be great (my older test system for Google Chrome lacks Vulkan support :o).
great thanks for looking into it!


will definitely try to test it over the weekend
unfortunately it does not seem to fix the problem. I still get the same warning that could not be load
Confirming this is also an issue on google-chrome-beta: (Excuse the unrelated dbus things) I'm not experienced at debugging this kind of thing but happy to give it a shot if there are any hints for where to get started. :) Edit: I did confirm that exists and paths seem valid.
If you have time it would be nice if you or someone else could use strace (or similar tools) to figure out where Chrome/Chromium is looking for . Something like (see - e.g. can be useful as well). It's a bit advanced though. I'm hoping that I can also give it a go soon (currently working on a few other Chromium TODOs).
Below is the strace output if it's any help. Pretty sure just the first ~2 lines are relevant. The first line happens when the browser opens, second line onwards happens after opening and the browser prints: (This is with stable, same thing happens with beta too). <details<summary<codestrace-fe file --timestamps google-chrome-stable OCLOEXEC) = 37 : 17:09:44 openat(ATFDCWD, "/nix/store/abmblk7xs49q0xhgkrp9izhab64jqri6-google-chrome-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/kxs3h7ffg2s061y9s8m00m5c6nbggg6f-libXScrnSaver-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/lbignzjfjydc4zb1d6qal3sjq7km3pqf-libXcomposite-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/6cy62r6hnzq5yqjj347p6dwv9pw21ixy-libxcb-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,


"/nix/store/1pj4gnng9ibcbd3cy4002lnyjwv2sjv3-alsa-lib-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/l9s8gcnh687p4cpkj0ic4ym180lpy9an-libXdamage-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/shjhw9gp0k78abd8mpd6jlgvbk17k2zv-libXtst-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/nfgwb2xk9jhidd4dh2l5j90kiyq17faa-libXrandr-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/pb2i4d6q7fai3kiqrw9za8svisyrngh5-libxshmfence-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/6hwhq9szpm65zhcvhfw42gzdlyi7b2rz-gdk-pixbuf-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/aqwqh3drn9bf6qrs70wiyrxaawh1wcnz-systemd-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/iy5g2611yc6y6jzcmpm55bjbskhcydkm-libexif-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/g7y8adgr5fac89kzfx8ddm66253a3idn-pciutils-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,


"/nix/store/19x7vr6vqvqcq1fqpdlk01c2gzb5igdm-curl-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/2jd06jm9lfis3knm615wm3idw86wjr3i-util-linux-2.37.2-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/qlxl487zbn873xqmp7gb3if3g250kdx7-flac-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/019a19l65k3qs88wr6fyznk7dj86a6vg-harfbuzz-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/jvbyjnjh4w8qg7izfq4x5d2wy9lv9461-icu4c-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/f76ccq4s20agzdz3m5fdmrs23r249fzr-libpng-apng-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/ani3r9bxx7il7zn54miylbxdn4lb2si5-libopus-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/ap050qq8w9xnpaijzhh4njhqarilam9c-snappy-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/86dp2ryfg8akpa9r3ylqd3fpdhqhzmxa-speech-dispatcher-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,


"/nix/store/ckqhvpa7mg8181pfhd4gb1k834npjm89-bzip2-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/90v7y17p3s4mqlx8hmd75y5acsq3x9pl-libcap-2.49-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/qk4xw57jvy68ca2aikj1gzbpxg9rigi1-at-spi2-atk-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/b8s1yzzi7s1wpy5j5jqhhv5cw2vhdjxh-at-spi2-core-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/mypff9f5vvf41wrjz76dialpsj2k3wq6-libkrb5-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/4xgbyn6sv265gv86rmjgfypmlhh2rvj8-libdrm-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/csxbwm4sr4swzk7qidp0x3lhlsqg6vw6-mesa-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/wwcpra73jl6hgqxl908k1b0810pd6wv4-libxkbcommon-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/njzhva8b2idhdfzaqr09kq4wfdlddxki-pipewire-0.3.40-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,


"/nix/store/7h5p0sd7acqvsw4jj4jygncmsq6sdcsq-wayland-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/a1b3p02cm1gsy16jwlgg00x9k3kp182r-libpulseaudio-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/pcs9vp9pcc2vqzvpjddqf7ifv951j323-libva-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/9a417mnzmkz7nbdq3kqpa5520qlggxga-vulkan-loader-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/5fpv8x3f6yzw0aqrslv3q126xx48lbn7-gtk+3-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/pwl7ygmix3skcz8xqz4pcm620vpr8bd5-nss-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/2nkjrh3za68vrw6kf8lxn6nq1dval05v-gcc-10.3.0-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/xnqj2w9szfw5mfwylhlavgxkiv9rslmg-sane-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/ldibnigsg44q3wp6v8ikn8kq08lf675c-glib-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD,


"/nix/store/bn7b7cidb9qgs8m8y83nf247j8j3xjsf-pango-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/q42c9s1cbyg5inf8ranys485akhaxh3v-cairo-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/w259jz35i221vil0jg2dpdw3zda55ai4-libX11-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/zbrzcprzpcby9107v8xkph2wks3mk93r-atk-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/pwl7ygmix3skcz8xqz4pcm620vpr8bd5-nss-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/5md0fgrd9jir7wdnxla46dfcb15vdsm2-nspr-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/cfv850gaqmzrs60fpxxkv088zcj74hi3-libXext-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/fgdh05bisfqs9llxvsg4c66ag9l78b58-libXfixes-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/lbignzjfjydc4zb1d6qal3sjq7km3pqf-libXcomposite-", ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/l9s8gcnh687p4cpkj0ic4ym180lpy9an-libXdamage-",


ORDONLYOCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/cgg7sv3aa40mksfrm44rfifcgprgd25v-expat-", ORDONLY|OCLOEXEC) = 257 : 17:09:44 openat(ATFDCWD, "/nix/store/zdmma38hz9jjks3dsm8qsmr006lnl0dp-cups-2.3.3op2-", ORDONLYO_CLOEXEC <unfinished .</pre</details
Temporary solution: or or, on flakes,
BTW, same problem with the . Vulkan backend only worked with the trick above
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Unfortunately this is still broken for me
This is still broken
Oh, seems like part of the issue is Vulkan is not supported on wayland yet
It's an upstream issue at this point, due to there being no Vulkan support on Wayland/Ozone:


Project description A simple one-file way to run various GGML and GGUF models with KoboldAI's UI. Metadata homepage URL: source URL: license: GNU Affero General Public License v3.0 platforms: darwin, linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
should be similar to llama-cpp since it is a fork but idk enough about both projects to do it myself
I'm currently working on this, although for to be packaged will need to be merged.


On or cross-compiled from , breaks: From : You can either run this on another architecture using . or should not crash: This was responsible for failing to replicate datasets to my ARM NAS. The issue does not_ occur for natively compiled builds. It appears to be a cross-compilation issue only.
It is a bug in / derivations. In non-cross cases it gets copied from used to bid into output: But in cross-case used to build does not yet provide as it needs bits of for it (and the library path is slightly incorrect). One of possible workarounds is to try to add to to get it pulled via from expected location.
We don't do the copying to glibc anymore, but this error still occurs as described on current nixpkgs master.
Yup. cross-compilation never propagated to in any form (and does not today).
Could you please try this PR? It should fix the problem.
With that PR, I'm seeing this on both (a Raspberry Pi CM4) and with QEMU on : Log from aarch64 machine: Log from machine with QEMU:
Well it's finding now, so there's clearly some other problem with addition to that. When I run it with I even get line numbers from inside : That line () is the last line in the following snippet of code: ... so is deliberately ing here due to . Grepping through the docs turns up: This is happening because uses . Once you do that, glibc needs to unwind the stack frame of any thread that calls . And unwinders are a giant headache. I'm afraid that's all I've got here. I've removed the closed-by from since it was only part of the problem here.
Ah, I think I know what it is. We can compile a without , but it won't have an unwinder. We need to pass the glibc headers to the build in order to get one of those.
would you please try ? I believe it fixes one of the two problems which caused this issue, and it includes which fixes the other one. It works for me: BTW, this issue (cross-compile , then run it under qemu) is a really valuable test case. We really ought to add it to so Hydra will catch any regressions automatically.


Especially since the failure mode gives the user no error message to help them troubleshoot the problem! is a great candidate for this since it's one of those very rare non-C++ programs that uses advanced stack-unwinding features from pthreads.
Confirming fixes the issue. Tested with both and on real hardware and with QEMU on x86_64.
~I think this is fixed, and more cleanly,~ by Edit: it is not. :frowning_face: I will keep trying. Test is in Currently building.
Added this to , but commented out since it is not fixed yet.


JupyterHub seems to be broken. Launch JupyterHub and sign in from the browser.


Project description <!-- Describe the project a little: --Configuration profiles manager and scheduler for restic backup Metadata homepage URL: source URL: license: GPL3 platforms: linux, darwin Previous discussion that could be a starting point:


Running the package after installation does not work. It results in an error instead of starting the app. Steps to reproduce the behavior: The application should start up and work. as per Please run and paste the result. Maintainer information:


Please update Goland to a current version. The Current Version is now 2020.1 Thx and Greetz


Describe the bug building the package fails. To Reproduce Steps to reproduce the behavior: and wait Expected behavior Successfully building python37Packages.pwntools to be used. Notify maintainers Maintainer: Metadata Error
Will be fixed via
lol, I didn't see this issue, I started fixing it today because I recently noticed it was broken as well :D


, (nixos-19.09) Scanned versions: nixos-19.09: . May contain false positives.
This is now fixed for 1.43 on master and 19.09:
Thanks :heart:


The option is declared as "list of packages". To me, it seems too restrictive, since it prevents useful configurations where web applications are copied from some mutable location in the filesystem, like this: . (Note that for tomcat's virtualHosts, the similar configurations are accepted and work fine just fine! I'm going to use them on my server.) Moreover, the current type was possibly chosen without much thought: it was a part of the long commit which mass- type specifications. My proposal is to change the type of from to . Right now, this kind of configuration produces an error: system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:


3 is out! I'm not sure what's changed but it's at least 200% more better, and has a plugin for making you toast :stuckouttongue: . The release notes are here: and are as follows: Anyway I imagine someone'll be excited about the new version :grin: so thought I'd share.
Haha, a proper changelog is here: my bad :innocent:.


Project description Pantheon Tweaks is a Switchboard plug allowing users to somewhat tweak Pantheon (elementary OS's DE) settings of the more hidden kind, not normally available from Switchboard. As NixOS has Pantheon packaged, it might be of use in Nixpkgs. Metadata homepage URL: source URL: license: platforms: same as Pantheon Depending on Pantheon version currently in Nixpkgs, the predecessor elementary-tweaks, also GPLv3, might be of more use:
As I maintain Pantheon in NixOS, I approve of this being packaged in the future, but not , because it's archived and IIRC I denied that .
Then we should probably do it once Pantheon in NixOS advances to whatever version elementary OS 6 Odin will have - this'll probably happen once elementary OS 6 will get released.
Ah yes, the repo says "Pantheon Tweaks is currently only supported on elementary OS Odin" :+1:
Did some initial work for this (), would you like to try that? Will need Pantheon 6 () and following line in your NixOS configuration file: Update: I will move this out from the pantheon namespace when creating the PR due to reasons below.
Did some initial work for this great! would you like to try that? of course works great. only the force darkmode did not work in minder program. haven't tested more... ! ! maybe it could be enabled by an option like ? So it's consistent with other options like .
Tested 1.13.1 on both elementary OS (installed via appcenter) and NixOS (btw minder in Nixpkgs seems out-of-date, just opened a PR: ), I guess this should be an issue to minder, as minder is trying to read information from of granite (, ), so it should respect settings from switchboard-plug-pantheon-shell, while what pantheon-tweaks does is (I guess) setting under you gtk config file and I am not sure how handle this. You can check this with: ! I am not sure as this is not an official part of Pantheon. I guess it should be okay to do this.
I am not sure as this is not an official part of Pantheon.


yes, that is a concern, but we can make that clear in the description do you think it is acceptable to enable a third-party component (e.g. pantheon-tweaks) with an option like if we clarify that it is third-party in the description, which is for example displayed at the or in the documentation?
I would not recommend packaging this tweaks app. It regularly breaks since it references gsettings that aren't considered API. That's just my personal opinion though I'm not familiar with NixOS options or what that means so I can't really offer an opinion there
thanks for your opinion! the program exists and people want to use it and we at nixos want to empower users to do what they want, even if the choices could be considered bad, like installing proprietary software. that's why it's considered for advanced users. you are responsible for the choices you make and you can end up with a broken system, but it's easy to roll back to a working state. experimenting is encouraged So i think it's fine for us to offer the package, but we can clarify that "it's not recommended by elementary because it regularly breaks". I'm not familiar with NixOS options or what that means so I can't really offer an opinion there i try to explain quickly: on nixos the whole system is configured by one (or multiple) config. file. as a consequence is read-only if you want to use pantheon, you add this line to the config: that sets up pantheon with default settings. there are options to change those default, like to remove default apps you don't need... so the question here is, all current options with in the name relate to official pantheon software, but would relate to third party software, which is not visible from the name. so it might not be 100% clear all the time so my suggestion is to clarify it at least in the description of the option that it is third-party and not recommended the concern is that it could devaluate you branding like the name "pantheon"
ah okay yeah. If possible then it would great if that was not namespaced with actual parts of pantheon and instead namespaced the way you would hand extensions or apps if there's no special convention for extensions. Thanks!
i suggest then


Commit introduced type specification for (which was absent before), but this specification is wrong. From within release-18.03, import the tomcat module from the master branch, and create a minimal Tomcat configuration that uses : And see it fails: When using the native module from release-18.03, everything works. system: host os: multi-user?: sandbox: version: channels(paul): channels(root): nixpkgs:
It's only semi-related, but why on earth is the type of a list of packages, and not just a list of paths or strings?? It severely limits the configuration options for no apparent gain.
For the record, was an issue about overly restrictive type of .


Steps to reproduce the behavior: 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


use instead of pulling the windows zip from github releases
I can review if you want to PR this
upstream has said that they'd rather us use the github mirror that they're going to set up
the github mirror has been created
Sorry, I have to delete the github mirror, due to bandwidth limits. Please use
the "SRB22.2" branch and/or "SRB2release_2.2.13" tag
Getting 500 errors when trying to access
does this work for you?
The link works however the download buttons don't. PRs welcome if anyone can get it working, but wait for to be merged first to avoid merge conflicts.
i have had another look, and have found that it might be better to pull directly from branch
Thanks, was able to get it to work with :+1:


Kdenlive build fails because CMake can't find QtConcurrent. Error: It appears to have been broken by some changes made to qtbase but I am not familiar enough with it to know what specifically. Changes between success and first failure: Latest Hydra failure: cc Attempt to install Kdenlive System: NixOS: 17.09pre107928. (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: "17.09pre107928." Sandboxing enabled: build-use-sandbox = true
You need to modify the to We should send a patch upstream. This must be a required change since QT5.8.
Fixed by:


Setting nixos option to null, which is legal according to typechecks results in an invalid disk size value passed to Launching the script, aka system build attribute , will throw an error at the disk creation stage mentioning an invalid argument for the size parameter. Steps to reproduce the behavior: new flake output attribute with value of basic nixosSystem option attribute ./result Launching ./result will create a qcow disk and launch qemu with the machine configuration. I found this bug through changes in nixos-generators. I've created an issue in their repo first, but their changes might be technically correct. REF; No maintainers list within that nixos module file. Pinging as last change author on the type of virtualisation.disksize. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I don't remember why I've set this option to . From the commit that it () it's clear that null is not handled, so it's probably a mistake.
Just stumbled upon this issue and agree with the analysis here. PR at


Project description Hashlink is a virtual machine used in Haxe/Heaps game projects. This is the same stack that shiro games and motion twin uses to make things like Dead Cells and Northgard. The full steps for installing heaps (which goes through dependencies) can be found , and one of the steps is to download hashlink and put it on the path. Metadata homepage URL: source URL: license: mit platforms: linux, mac, windows
I am on it, will try to compose a first draft. :-)
That was fast! I really appreciate it! I put in a few haxe-related package requests today, I'm so surprised no one else has requested them before! But once they're in we'll be happy! Not really looking to nix-ify my haxe projects yet since I imagine it'll be involved, but getting hashlink on the path in a package is a step in the right direction right? :) Really appreciate this, thank you!
I'm not really familiar with the Haxe ecosystem, but the Arch build for Hashlink suggested that this packaging task seemed simple enough (no complex build system, just a Makefile, no dependencies on other parts of the Haxe ecosystem) so that I could do it. Glad that I could be of help. :-) Thank you for your issue contributions! While the pull request is not yet merged, you can use hashlink as follows: (Be wary that commands like this can cause the execution of arbitrary code, so in principle one should use these only with trusted repositories.)
Thanks for your hard work!
how are things going with the PR? I think someone has asked a question on it, I don't know if that means that it's stalled from going in? Thanks again!
There are in fact issues with hashlink on NixOS I think - I think there's some libraries that are build with hashlink that are unhandled - there's an issue for this already as hinted in your PR:


When running OmniSharp, the program is unable to find a dotnet runtime to use at all. When I remove the part from the part of the script, it starts to work. Presumably because moving the command to /dev/null just isn't helping at all? ! !
Oh this is an issue with buildDotnetModule. I was looking at nixos-23.05 when I am on nixos-unstable.
So I am not the only one having this issue I talked about this in the PR that introduced the bug (). I have made a proof of concept for a fix: I will open a PR for this, now that I know that I am not the only one experiencing this.
Your fix worked because, because the original code is checking whether you have dotnet installed by checking whether has an exit code of 0 (which it does, if it is installed). But if you change it to , it will always have exit code that is not 0 (because running is not correct by itself), thus making it think you don't have it installed, which means it will use the hardcoded dotnet 6 version instead.
Yeah, I just stumbled upon it while copy pasting the script manually, I didn't take the time to understand what was happening, still new to shell-scripts. Thanks for hopefully finding a solution!


efibootmgr is not a dependency, despite being needed Steps to reproduce the behavior: refind refind-install the error message: ! efibootmgr is a dependency of refind I already had refind installed (from another distro) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description homepage URL: https://xd- source URL: license: mit platforms: linux
I marked this as stale due to inactivity. →


shogun fails to build since the eigen 3.4.0 bump: The package is a likely candidate for removal. Upstream is unresponsive and development has halted. Removed from debian: Removed from fedora: Blocking vcpkg update: Please run and paste the result. Maintainer information:
I think you were the last one to modify this package, so please speak up if you need it. Also pinging Last call - if no one responds within the next week, I'll open a PR to remove this package.
Yes, I was working on making it build on Darwin and adding it as a Python 3 module. Well, I did, but I didn't feel motivated to create a PR. As you comment, upstream has been inactive for almost a year, the latest release is several years old, and it becomes harder and harder to make it work, and the patches would start to accumulate. To make it work on Darwin we need two upstream patches that fix the build with newer compiler versions. In the current derivation, the Python interface is not built because the CMake flag is not the right one. When enabled, Swig 3 is used to generate the Python interface, but Swig 3 doesn't support Python 3.8+ (and with Swig 4 just fails). It can be fixed with a patch, that feels more like a hack, intercepting the Makefile build, so I am not happy with it: Another small patch is needed to fix the deprecated . Also, I wasn't happy that adding it as a Python module will recompile the entire library again, which takes too much time IMO. I haven't checked if it is possible to build with Eigen 3.4 because it takes forever to compile. It could probably work on the development version. Note that the development version doesn't support Eigen 3.4 because of this, but it may work: But there is no such limitation on the 6.1.4 release, which probably means it would require another patch to fix the code, if somebody figures out. So, I'd argue that the package is too old now, and the derivation has too many issues, and it's too much of a hassle to maintain it, so it's probably better to just remove it.
I decided to sit and take a look at the error, and I actually fixed it.


I don't really use Eigen but the patch makes sense. So, I can send a PR to keep this package on the repo for another cycle at least. I mean, I already did all of the work and it builds. Other distros end up removing it because nobody cares to maintain it.
Nice! Thanks for looking into it. Like you said, if you've already done the work to get it working I don't see why not. If it's too much work to keep it working in the future we can always revisit this and drop it.


In NixOS VM tests, service sometimes fails to start. This breaks e.g. GlusterFS tests. Steps to reproduce the behavior: Building — GlusterFS service fails due to dependency on RPC Bind service. See also Some result related to GlusterFS. Have not yet had time to bisect and determine what's going on.
Hey, I started down this path looking for an updated Glusterfs package, then found the paused PR, which linked here. Fortunately, I think I know the root cause. As you noted, the failure is due to a dependency failure on - the error message in journald is: This was sort of confusing, but I found that led me to . The NixOS config includes: L /var/run - - - - ../run So my suspicion is that starts before and can't check for the lockfile. Since there's no unit, which was my first guess, I've instead been adding and tied to , which makes the tests pass. The diff that makes this work is: Obviously we should probably make this fix in NixOS proper, but I want to double-check with you that such a wider-impact change is safe to make. The proposed global_ fix for NixOS would be: thoughts/feedback? I can PR the fix if this all sounds right.
The real problem is that I am competent about neither rpcbind nor systemd-tmpfiles (otherwise I would try to write a more sensible complaint). Maybe PR the change (if it indeed fixes rpcbind judging from logs + fixes GlusterFS tests + doesn't break any NixOS tests that passed right before) and see if more competent people show up? It does feel to me that ideally tmpfiles should not depend on rpcbind and if they do (dunno, because we have /tmp on GlusterFS???) we are doomed anyway…
You and I are in the same boat, friend :joy: I'm only rpcbind-aware as it applies to GlusterFS, so I don't count myself as an expert, either. The only reason I feel confident enough to PR a fix is that all the pieces line up here and the passing tests make me think that this does indeed strike at the root cause.


If NixOS is shipping with that tmpfiles configuration to bootstrap , then I think it makes sense for the downstream NixOS module to accomodate how NixOS is handling . So my initial instinct of patching upstream probably doesn't apply since distros are probably handling differently. I'll PR the change and we can see about additional feedback for us.
I'm feeling pretty confident that fixed the rpcbind problem - are there any nixosTests that should be re-enabled now that rpcbind reliably runs? I looked around for disabled tests but am not sure where those might live, if any are still disabled. Otherwise, I think we can close this :crossed_fingers:
(looked at the tests, doesn't look like there is a ton of disabled ones)


Describe the bug Epiphany crashes on startup with a bind mount error. To Reproduce Steps to reproduce the behavior: epiphany Expected behavior The browser should startup Additional context Error: exists and opengl is enabled I bet is relevant Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Maintainer information:
I can't reproduce this on my machine. Can you try running it with ?
Thanks for responding. I think this is the relevant part from :
Ah, this only shows that emits the error message. To trace what it actually does, could you try adding the flag?
I just piped it all into here:
The output got cut off there, unfortunately. Maybe you could just attach the text file directly to your reply?
Sorry about that, here is the file:
Thanks for the log! I think I've found the culprit. I've opened which seems to fix it - please try it out.


Package name: tailscale Latest released version: 1.72.0 <!-- Search your package here: --- Current version on the unstable channel: 1.70.0 Current version on the stable/release channel: 1.66.4 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Grocy does not properly save manuals for equipment The issue appears to be introduced by in a patch applied by nixpkgs. Changing that hunk to: Fixes the issue. I'm not currently setup for making a PR, I'm a bit busy, but I wanted an issue for other people to find if they run into the problem. grocy in nixos configuration (admin/admin is default) a new piece of equipment and attach a PDF manual to it to download manual; it will fail system: host os: multi-user?: sandbox: version: channels(aidenn): channels(root): nixpkgs:
appears to be the maintainer.
I marked this as stale due to inactivity. →


Would be a very useful package to have for ML Enthusiasts Project description Machine Learning Catboost Library Metadata CatBoost is a high-performance open source library for gradient boosting on decision trees homepage URL: source URL: license: Apache License 2.0 platforms: Linux installation instructions: Please let me know if I should stop tagging you in random issues and it bothers you (sorry, i'll stop), but I thought this might be of interest to you since you are very involved in tensorflow.
taggining maintainers of xgboost and lightgbm. Wondering if you could look into compiling catboost too?
I use tensorflow at work, which is why I care :). But I'm not a data-scientist
understood, thank you. GPU support for catboost would also be very welcome.
Looks like they have a non standard install script. But definitely doable. Sadly I don't think I have time in the near future but would be happy to point you in the right direction to get stared with a PR
both eyes wide open - i'll try to start this w/e, any pointers very welcome, thank you.
Currently failing to build on nix, although the file clearly exists.
- maybe it's easier if you create a work-in-progress pull request so other people can check? Two things that stand out are: looks like something is being downloaded during the build process. This won't work with sandboxing because there won't be a working network. builds should be isolated, i.e. access to should be rewritten to the local build directory, not (probably hardcoded somewhere in the build scripts). Packaging for nix can be quite fiddly - I think might be a good example for fetching complex dependencies + build script patches.
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 .


Clang's wrapper does not set as an include path. Compiling files with since <cxxabi.hrequires is present in the aforementioned path I created the environment using this minimal mkShell expression Adding to
Proposed solution seems reasonable to me. See also started by
Please can you also include the nixpkgs commit hash in the repro (sorry if it's there and I missed it).
Oh thank you, that makes so much sense, I was also looking at how the monorepo handles things as well as their tests on finding the system include headers and what you said is probably the correct reason. Ah, it was the nixpkgs-unstable revision updated just then. Sorry I do not have that, but you can reproduce it with the current master as well.


Package name: tracker-miners Latest released version: 3.7.3 <!-- Search your package here: --- Current version on the unstable channel: 3.7.2 Current version on the stable/release channel: 3.6.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. -- Tracker was updated in , however tracker-miners wasn't. It currently suffers from this bug: (and generates a lot of failures on a running gnome system). It was fixed in 3.7.3. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
PRs are welcomed.


Which version does it attempt to build? See for explanation.
9
Hmm, are you sure procps(-ng) can work on darwin? I found just
The only reason I wanted it was for the utility, which does work on Darwin. Homebrew has a separate installation target for , so maybe we can do that too.
I see, I noticed that. I'll leave it open then.
Since there is now a specific watch expression, this is no longer a bug.


Package name: atuin Latest released version: 18.0.1 Current version on the unstable channel: 18.0.1 Current version on the stable/release channel: 17.0.1 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]:
If you are planning to open a PR anyway, you don't need to open an issue.
Cool, thanks. I was unsure of the policy around that


Project description httm prints the size, date and corresponding locations of available unique versions (deduplicated by modify time and size) of files residing on ZFS snapshots, but can also be used interactively to view and restore such files. httm might change the way you use ZFS snapshots (because ZFS isn't designed for finding for unique file versions) or the Time Machine concept (because httm is very fast!). Metadata homepage URL: source URL: license: Mozilla Public License 2.0 platforms: unix, linux, darwin
Oh great thanks! Searched first but missed this.


Package name: ko Latest released version: 0.15.3 <!-- Search your package here: --- Current version on the unstable channel: 0.15.2 Current version on the stable/release channel: 0.15.1 <!-- 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]:


As noted by scipy uses the wrong tests. Instead of running its own test-suite, it runs that of numpy. This is because accidentally pkgName was set to in
Most errors are which are harmless according to
The 12 errors that are encountered are in fact 11 deprecation warnings, and one syntax error in a test when setting PYTHONPATH.


Describe the bug To contribute to the nixpkgs documentation I followed the instructions in the nixpkgs manual "Chapter 21. Contributing to this documentation" and I followed the code snippet Firstly I was greeted with some warnings: But moving on to I saw a large number of errors. It looks like is set up inside the nix-shell but it's not picked up by ? Running the command does work. To Reproduce Expected behavior No warnings, no errors. Metadata Please run and paste the result. Maintainer information:
nix-shell has a specific setup to allow running stdenv phases such as
That also gives me a bunch of errors as well, but different ones: For a bunch of files. I managed to write some updates to the docs and validated them just using the command, but it's a bit unfortunate that just following the instructions literally doesn't work.
Sorry about that. should fix it.
Thanks, that fixes it for me (tested by setting the env variable manually). Great to see these steps towards making it easier to contribute to the docs.


On my M1 Mac, with homebrew-installed libvirt / qemu-system-aarch64, I'm able to run the VM defined in the config below without issue. However with libvirt / qemu installed via nix, I get: Some possibly related discussion . Looking at the , they're explicitly setting ; adding this seems to resolve the issue: I'm not sure whether disabling those failing tests is a reasonable thing to do. Steps to reproduce the behavior: to in A clear and concise description of what you expected to happen. Should run without , like it does with homebrew. Please run and paste the result.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
FWIW, I also encountered this issue, and have to use the following workaround: And -ing the efi firmware & vars manually. Fixing this bug can lead to great user experience: virt-manager can work out of box.
Where did you get ?


Package name: river Latest released version: 0.3.3 <!-- Search your package here: --- Current version on the unstable channel: 0.3.2 Current version on the stable/release channel: 0.3.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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
3 is only a zig 0.13 compatibility release. It’s blocked by
has been merged, this is not blocked anymore.


<!-- 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: lapce <!-- 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: 0.0.10 desired version: 0.0.12 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Maybe it will fix the crash:
can you create a pull request?
I am using changes in local build. it is working fine


DBeaver has support to show spatial data on a map when the database is capable (e.g. postgres + postgis) but opening "spatial" tab gives this error: Steps to reproduce the behavior: dbeaver to a table that has a geometry, show data "Spatial" on the left A map should be shown This happens on master and 21.05-release, didn't test on 21.11 but I suppose it's the same Maintainer information:
I was able to reproduce the error and have fixed it. This is how the map now looks with a sample polygon taken from !
Wow that was quick! Thank you a lot!


Describe the bug When adding a local directory to spotify client, it always fails due to missing gtk schema(s) To Reproduce Steps to reproduce the behavior: on button Expected behavior Open a file chooser to select which directory to be . Screenshots If applicable, add screenshots to help explain your problem. Additional context Running spotify with flag from console gives me Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Maintainer information:
I think that this issue is not NixOS specific:
Still seems to be an issue. I'm using flakes so above is not applicable I'm on.
Tail end of strace.
Yep I can confirm that. However, as IvanMalison commented above, the bug might be not by nixos but by upstream.
I'm getting the same issue as OP when clicking the button I also tried this on EndeavourOS with the same version of spotify and there it works flawlessly. So I think this is actually a nixpkgs problem and not something upstream related. Maybe the issue can be reopened?


Using Shogun as a for another CMake-based project fails because the dependent project cannot properly find the shogun library (via its installed cmake files). Steps to reproduce the behavior: to build a derivation based on shogun files are wrong Everything builds correctly I am trying to build the following derivation However I get an error at the build generation step: This indicates that shogun CMake files are not in the right place and/or are pointing towards the wrong paths.
I fixed the issue with shogun. When installing the configuration files, CMake calculates the prefix to the installed library based on the output directory, instead of the default , and I missed it when I split the derivation into multiple outputs. I wonder why it's not a more widespread issue, only a few derivations patch it. But that derivation still doesn't build: This is in macOS, though. Maybe it works on Linux.
Thanks, is the fix committed yet? The other error is unrelated and I can fix it.
I'm working on the PR.


Since is provided by the non-free on aarch64, I'm not able to install asciidoc-full or any software that requires it to create e.g. the man pages. Can we make an option different from ? /cc
Making new granular options is fine, but I think enableStandardFeatures should still include java. (Or else the option is dishonest.) Alternatively, can we switch to openjdk (assuming that works on aarch64)?
It was just recently changed to in I'm fine with granular options, even though it will be quite some work to make packages not use anymore.
Oh, so this problem is due to licensing, not wanting to use non-free software? I didn't pick up on that earlier. How about adding a disableJava option, that has priority over enableStandardFeatures? Hm, this feels like a local solution to a global problem.
is a good idea! What do you think should be the default?
If enableStandardFeatures is true, you should get java. Setting disableJava then enables standard features except those requiring java. I'm not sure if doing this (per package) is a good idea though. Isn't this the start of a new whack-a-mole game?
Yes, it's certainly not a perfect solution, but I can then use an overlay which sets for . Alternatively, we could enable Java for x86 only by default.
Perhaps it would be less confusing to have so the additive condition is positive.


Discord's package has a script which disables breaking updates, by looking and modifying the file. This script breaks if said exists but is empty (fails to load the JSON object) For some reason all values in this file cleared to me and I encountered this issue. (tested on NixOS 22.11 but the script hasn't changed in master) Steps to reproduce the behavior: discord discord should not launch at all (silently, unless launched from a terminal) should handle the exception which arises from this issue. N/A Some logs of when this happens: <!-- 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.
Hmm, interesting that Discord doesn't launch at all. This is a pretty simple fix though, Or something like that (Now that I think about it, if the doesn't exist yet, the script could create it)
Tangentally related: I installed discord on a new machine, and the disable breaking updates script didn't appear to have any effect until I created an empty containing just . There were other files in , but not . Creating that would be nice. Also, the only real indication that it was missing is that when I ran from a terminal, the first line of the output was . This is quite easy to miss because it's at the top of the output, so maybe it would be good to show these errors in a dialog or something similar.
I'm surprised this is even in tree - I don't think we should be changing program behavior - especially when you're calling it . I doubt the majority of the users even knew this was happening outside of those involved in PRs for nixpkgs. This is a matter of convenience like stated in the script that has a trade off causing a degradation in the security of the application - causing users to not update - relying on maintainers to do it. Please create a separate package for this at the same time when fixing this - call it whatever - just not . Or enclose it in an arg that is disabled by default.
I hit this same issue and adding an with contents got it running for me as well.
Thanks for opening an issue and describing the fix. This broke for me too and it took me a while to figure out why ...
This issue has been mentioned on NixOS Discourse. There might be relevant details there:


Package name: sunvox Latest released version: v2.1.1c Notify maintainers
The current version in nixpkgs is not available so building fails. The hash of the new version is


Project description forwards dns over https queries to normal dns servers and vice versa. Metadata homepage URL: source URL: license: apache 2.0 platforms: unix, linux, darwin, ... ubuntu package url:
Upstream has system services. Is there a need to include these modules (services) within this package? I would prefer not to include them if there is no need, because is not actively developed and has not released a single stable version yet.
I personally don't need them, because I prefer creating systemd services via nix configuration anyways.


Project description Catamaran sans is a font for tamil language Metadata homepage URL: source URL: license: OFL platforms: ? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description A window switcher, application launcher and dmenu replacement (Wayland fork) Metadata homepage URL: license: mit platforms: linux


Blender 2.93.5 Hallo When I start Blender now and set under “Render Properties” → “Cycles” Blender crashes completely. Also when I go to “Edit” → “Preferences” → “System” Blender crashes immediately with this Error: What does that tell me now? My GPU configuration in the clinfo: nix run -c nix-info -m:
I think this might be the same issue as described in


Describe the bug Blender segfaults when an OpenCL render is attempted. To Reproduce Steps to reproduce the behavior: Properties (right panel) Select Cycles, change device to GPU Compute Expected behavior It should render. Additional context May be related to and Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information: Blender gdb backtrace: I'm using a Radeon VII with: gives me:
cc
This seems like an upstream issue. The question is which upstream? Does the crash also occur with e.g. the Intel OpenCL runtime?
FWIW, I also see the segfault on an rx580 following the repro instructions. It does like others have Blender working with ROCm OpenCL, so the crash may well be due to our packaging. did such a nice job cleaning up our LLVM derivations that there's much less room for funny business now than with previous releases. I see that we have a option we could give LLVM which might reveal a bit more information?
I can also reproduce the problem on a RX580. Here somebody has the same issue, with a plausible explanation: The conclusion there is that it occurs when two different LLVM versions are used in a process. Which would be the case here, since Blender uses OpenGL. Currently our Mesa is still on LLVM 9, whereas ROCm uses LLVM 11.
Yep, this is probably the issue. If I compile the derivation with a built against , I don't get the segfault. I am not sure yet what the solution is, since we cannot always update the LLVM version that Mesa uses to that of ROCm. I wonder how this is dealt with with ROCm on other distributions. Do they override the system Mesa?
I guess I should have turned up that link first given my prior involvement! Could we substitute a at runtime instead? Perhaps via ICD, or , or even ?
There is , which we could use to override system package. I guess if it works, we could add a module along the lines of the support, which would use as the OpenGL package and could even add the ICD definition to .


But we should probably first test how well building mesa against the LLVM fork works. At least it builds ;). I might have some time to look at this after work.
If you have a chance, could you elaborate on how you did this in nixos?: I understand that it's not the permanent fix, but I'm quite curious to try it.
I modified nixpkgs in-place, but you could do something like: And then: A more proper solution would be to switch to a -built Mesa for . I do have a branch for this: or the two commits: But I ran into another issue in Blender, and I didn't have time to investigate. The system (including GNOME, etc.) worked fine with Mesa built with llvmPackages_rocm.
Sorry. I misremember. I may have rebuilt my system with Which should be equivalent to having an overlay But I am a bit nervous about switching Mesa to a vendor-forked (IIRC prerelease) of LLVM. We should just document this incompatibility for 20.09 and then perhaps land something like the proposed branch/module in master/21.03. But that definitely requires more testing.
i tried your amdgpu-rocm thing but now blender crashes with this error when opening user preferences: is this the error you mentioned you didn't have time to debug?
That's the one. I am afraid though that I can't help with any further debugging. I had to replace the RX580 in the machine I was testing on by an NVIDIA card, because there were too many issues with training machine learning models on the RX580 :confused: .
this seems very similar to and replies there would seem to indicate that it's still some LLVM incompatibility, but i'm not sure what is incompatible here... is it blender itself?
I think the core problem is that both OpenGL and OpenCL (through winding paths) each load their own instances of LLVM into the process, and those instances of LLVM somehow end up sharing some global data, with usually disastrous results.
It seems that upstream now explicitly states that ROCm is only for headless deployments: Given the risks of compiling Mesa against a vendor fork (we get to fix any bugs), I think that we should just document this in the AMD -OpenCL section of the manual and leave it at that. Do you agree ?


Given this and the lack of RDNA support, I guess the future of OpenCL for GUI apps is with Mesa's Clover.
I do agree, yes. An AMD employee has been trying to walk things back, but who knows. It doesn’t make sense that they just switched their consumer driver to use ROCm for OpenCL if they don’t have a vision of getting in sync with Mesa, but that’s clearly their row to hoe.
I'm amazed AMD has any foot left to shoot at.
I marked this as stale due to inactivity. →
Still important, though only in general (OpenCL in GUI apps with AMD GPUs), because .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I think I finally figured out a workaround! Disabling for seems to work. I did it with the following patch to nixpkgs, but it should be possible to do it with an overlay too: After a lot of building, Blender seems happy again :) !
If this works, it is incredible. How would I do it as an overlay?
I think this should do it. It's ugly and there might be a better way but it should at least make it easy to test if it works for you. I'm still trying to figure out if there's a simpler fix (for example, overriding just ), but haven't been able to figure it out yet.
It works for me. I suggest you make a PR with this change to Nixpkgs. It may seem a bit ad-hoc, but otherwise it is not possible for a process to have both OpenGL and ROCm OpenCL loaded simultaneously, which seems like a pretty common use case.
Now that I know it works for other people I'll try to make a PR in the next day or two, yeah :)


Steps to reproduce the behavior: kicad (tested on ) The relevant part of the build log is: Complete build log is here: Setting the flag in the cmake build flags, solves the issue. Please run and paste the result.
thanks for filing an issue i'm not sure what changed to cause this issue, or why that change didn't notify me of the breakage... i'll try to get your fix or something similar in a PR today


Steps to reproduce the behavior: working program Add any other context about the problem here. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:


On NixOS 22.05, getting financial quotes in gnucash no longer works because the helper scripts are now binary wrappers, but gnucash calls so this fails. Commit suggests that should avoid this, but for some reason the scripts still get wrapped with binaries. NixOS 22.05..
I can reproduce this on my machine from nixpkgs/master, so it's not a 22.05 problem. Interestingly, when I backport GnuCash's derivation from nixpkgs/master back to a known-good commit (), things appear ok. I'll continue digging.
... I see you yourself as a maintainer. Any interest in taking a stab at this? Per I think we're being broken by a change somewhere related to .
... I see you yourself as a maintainer. Any interest in taking a stab at this? still getting my head together after a bad bout of covid, not sure I'll be able to work on anything serious any time soon
I worked around this on my nixos config by adding a patch () to execute the helpers directly without calling out to perl. It seems to work for me. Will this break anything? If desired, I can submit a PR with this patch. Also, the perl helpers seem to be getting wrapped explicitly () is this not the reason the perl helpers are getting wrapped with binary executables?


Package name: fragments Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 2.0.2 Current version on the stable/release channel: 2.0.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.


should provide a QT client to freeciv, which is probably named if I had to guess. Steps to reproduce the behavior: only gtk client installed (see below) A executable. If applicable, add screenshots to help explain your problem. ! -( does not exist) ! The installed is indeed a gtk client. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- (You were the last person to commit, so I choose you :) ) (I don't believe the listed maintainer exists). Please run and paste the result. Maintainer information:


Steps to reproduce the behavior: cutter 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Any news on this?


It's not possible to lock screen in xfce unless "xlockmore" is installed. in in XFCE and try to lock without success and then retry to lock System: NixOS Emu Nix version: 1.11.2 Nixpkgs version: "16.03.973."
I think that's because there is no blessed lock screen for XFCE. tries XScreenSaver, GNOME Screensaver, XLock and SLock -- in that order.
Has a situation like this (multiple optional but at least one required dependency on an executable) already been handled in NixOS?
I think this is generally resolved by some kind of switch, but we have to add one. Something like of ...
I kept as-is: see
I think the issue may be resolved. At least with (as of 2023-09-17) lock screen is possible without having installed.


Project description linux-wallpaperengine aims to reproduce the background functionality of Wallpaper Engine on Linux systems. There already is a wallpaper-engine implementation packaged, but it only works on KDE, while this project should work with most Wayland-compositors and window-managers. Metadata homepage URL: source URL: license: gpl3 platforms: linux I tried to package it myself, but the "just compare with other packages" approach of the nixpkgs documentation was very confusing to me. If someone can point me to other documentation or anything helpful I'd be happy to try it again.
Sort of, it still runs under X fyi My rough process: check the repo of whatever you're packaging to see what language and tooling it uses read the nixpkgs manual for the language and tooling that you're building with find examples of other expressions in nixpkgs that use the same tooling to get an idea of the structure use something like to generate the boilerplate for the expression , get an error, use to find the required dependency (repeat this step until there are no more build errors) submit PR


Steps to reproduce the behavior: to NixOS config Successfully start. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Project description <!-- Describe the project a little: --Syntax Tree Surfer is a plugin for Neovim that helps you surf through your document and move elements around using the nvim-treesitter API. 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]:


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. Add a :+1: [reaction] to [issues you find important].
PR:


I've hit the same bug as described in The root of the problem seems to be missing configuration file which should be placed somewhere and made accessible by . It is used by, for example, in Emacs. cc
cc
I'm just getting this warning: Otherwise the output seems normal to me, but I've never really used the utility.
Oh, I see, is still a problem, as it used to be in Debian.
Actually, that config file is provided by package, so if I include it in , it works fine even with . Still, it's a bit confusing that the core provides binary but doesn't fully support it.
I currently can't see a simple way how to improve that.
I am not able to use on because it does not accept the option . In the command line I get: Is it related to this issue, or should I report a new issue?
cc When explicitly adding to there are checksum errors. The following patch fixes it for me: With that, does not give the error anymore.
Oh, no, they're updating files in-place on the only mirror. Many of them won't download anymore :angry:
Better discuss the mirroring stuff at this thread:
triage: this might have been fixed in the meantime, is that so?
it's still necessary to explicitly add the package, otherwise the problem persists.
Could anyone, please, provide steps to reproduce?
The "chktex -v" works for me, I have installed with .
works in but not .
This issue still persists as of today under the tetex scheme. the addition of the chktex package is mandatory to not get this error. I was getting this error in emacs: chktex: WARNING -- Could not find global resource file. chktex: ERROR -- Illegal verbosity level. I didn't thought that this was a NixOS related issue so this thread was quite hard to stumble upon.
I can't reproduce:
I guess I forgot . If I include that then it just gives "chktex: command not found". So how do I trigger the issue?


fails to build. Looking at hydra when it started to fail () it could be due to GCC 11 update. Just adding to the only leads to the next error. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --


Steps to reproduce the behavior: try to install/build the package using nix-shell or nixos the Domain is no longer configured. Teamspeak Download Pages redirects to this place: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
You might want to check out
Not merged yet
As a workaround, until this is fixed in nixpkgs: The file is still available at the Internet Archive. You can fetch it from there and write it into the store, with something like this:


Describe the bug The stable channel was last updated 5 days before. The blocking issue seems to be the build of nlohmannjson timing out. To Reproduce Steps to reproduce the behavior: to local nixpkgs repo: latest changes: stable channel: : That works, so there is no actual issue with the build. The problem is that a test times out on the CI: Maintainer information:


After commit, just enabling does not work because node-red package is under Steps to reproduce the behavior: enable Pull package correctly ! I think the package option should be something like this instead of easy fix I guess I don't know where is found for nixos modules <!-- 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]:


Describe the bug When i open the About dialog in any program provided by gnunet-gtk, for example , i notice that the logo is missing. ! To Reproduce Steps to reproduce the behavior: (wait for ) Help -About Expected behavior no icons missing Notify maintainers (who fixed the build last) Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
PR:


on Hydra: cc
Since it's been building for me, checked if I was sitting on any changes and while the commit message doesn't indicate that it fixes anything (eep), it does seem to fix this issue: Don't remember enough details to justify it fully offhand (again d'oh for not writing it down at the time hehe) but hopefully this helps work towards a suitable resolution :).
Naturally this breaks in as well.
Yep, broken for me too. Haven't had time to tinker yet.
I have the same problem, but the commit mentioned fixes it for me.
So are we just waiting for this commit to be in the unstable channels?


A Go program compiled using nix-shell returns an error when running on a separate server and trying to load a timezone file. file with: $nix-shell $<inside shellgo build $exit $ ./app # name of the app you just created 2019/01/25 20:04:58 All went well: America/NewYork Now copy this file to another computer #./app 2019/01/26 01:01:34 could not load new york locationopen /nix/store/0596k27r6pacyx4jp1bcn8zqyjhji52l-go- no such file or directory The error includes the zip name due to internal reasons the Go team has, but the real problem is that nix replaced with I would be more than happy to send a Pull Request if you agree with the proposed solution of prepending instead of replacing. $ nix-shell -p nix-info --run "nix-info -m" these paths will be fetched (0.00 MiB download, 0.00 MiB unpacked): /nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info copying path '/nix/store/dzvh4f6ihkwg44mmf2awxg564k1s8khg-nix-info' from ''... system: host os: multi-user?: sandbox: version: channels(diego): nixpkgs: version is nixos-unstable-2019-01-22 The file replaces the path that the go runtime looks for the timezone information. Original Go code is: But nix changes the first entry, for This works fine if you end up running your go application in the same nix env you compiled it, but when you deploy your go program to a separate server, the path, that can look like isn't present on the separate server and then the lookup fails. is a very common path in Linux distributions. A better way to solve this would be to prepend the nix only path, as the first entry, and then keep and the other entries as they are in the original go source code. The benefits are that those who compile and run in the same nix environment will use the nix path, but those who deploy somewhere else won't have to do any extra work.


I doubt anyone ever considered support for non-Nix and therefore I will mark it also as . I'll leave it open for now as maybe it can be supported (I doubt it).
would you accept a PR with my proposed solution? It won't hurt nix deployments but will help a use case of building a go program in nix but deploying outside of nix.
cross referencing a thread on the mailing list about this ticket/issue so both conversations are linked.
Your explanation and proposed solution seem to be very reasonable to me. I suggest that you submit a PR.